> For what scheme implementation are you using? And where can I
> get what you are using?
I use Matthew Flatt's mzscheme, which is part of the PLT project, see
<www.plt-scheme.org>. I run it with a two line patch to put the Boehm
GC into incremental mode.
There is a pre-release archive at <www.alphalink.com.au/~rd>. I have
used this and James McCartney's SC3 synthesis server, see
<supercollider.sf.net>, as my work environment for over a year and it is
stable, however unless there is a particular affinity for Lisp I would
recommend using James McCartney's Smalltalk dialect as a language
client.
Regards,
Rohan
Hi everyone,
Just wanted to put in a plug for IETF-based solutions
to doing service discovery for OSC -- basically, this would
entail using SIP:
http://www.ietf.org/rfc/rfc3261.txt
for session management, and SDP:
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-new-15.txt
to describe the sessions themselves. To specify OSC
in SDP, you'd use UDP or TCP as a transport specifier on
the media line, and make up (and eventually, register) a "fmt"
parameter for OSC.
One of the things I'm planning to do now that RTP MIDI
is finally nearing Last Call is to look at session management
frameworks for RTP MIDI that would use SIP + SDP. If OSC
went this route too, applications could use the Offer/Answer
protocol:
http://www.ietf.org/rfc/rfc3264.txt
to negotiate to use MIDI (for baseline support) or OSC
(to do more sophisticated things). This was one of the
motivations behind RTP MIDI -- to offer a migration path
from MIDI, without requiring backward-compatibility between
control languages ...
---
John Lazzaro
http://www.cs.berkeley.edu/~lazzaro
lazzaro [at] cs [dot] berkeley [dot] edu
---
liblrdf is a lightweight RDF metadata handling library with extensions for
manipulating LADSPA Schema-specific data.
http://plugin.org.uk/lrdf/
This version adds:
* MacOSX compatibility, courtesy of Taybin Rutkin
* A convienient method for reading control scale points
* A convienient method for writing preset information
An example showing how to use the two new methods can be found in
examples/scale_test.c and examples/setting_test.c
Scales are a way of mapping the semantics of port values to labels, eg.
that an oscilator wave control has known behaviours for 0, 1 and 2 mapping
to "sine", "square" and "saw".
An RDF scale description of his plugins is included with Tom's Audio
Plugins (http://www.hszk.bme.hu/~st444/tap/tap.html) and an RDF
description of the scales for mine is on the website
(http://plugin.org.uk/src/metadata/swh-scales.rdf, you can install it in
/usr/local/(share/)ladspa/rdf/) and will be included in the next release.
- Steve
>From: "Doug Wellington" <ddw(a)dakotacom.net>
>
>Previously:
>>> Reminds me of that old saying, "Linux is only free if your time
>>> isn't worth anything"...
>>
>> True, sort of, but you have to remember that "there's no such thing
>> as a free lunch."
>
>TANSTAAFL - exactly! There's always a price. Either you do it
>yourself, or you have someone else do it. Time vs. money...
Or, either you do it in N months or someone else do it in a week.
The sentence "you have someone else do it" does not sound very
realistic: 8 years ago I suggested first time a simple rectangular
re-adjustable selection tool to GIMP. Once again I suggested it
a few weeks ago and the task was again "assigned" to me even I asked
a coder with who together I could have implemented the thing. Now
GIMP does not compile in my Linux which means automatic delay of
several months (more likely a year) before I have a change to get
new Linux distribution. The tool would be highly needed as GIMP does
not have a re-adjustable rectangular selection tool (it's currently
only "if it went wrong, start from beginning"). Like having audio
editor without re-adjustable selection tool.
I simply don't understand why capable GIMP developers cannot implement
the simple feature. There is no sense in that I should learn GIMP
internals -- I could use that time for developing my own projects
instead of wasting the time to sidetracks.
Regards,
Juhana
Hello.
Below is an unfinished list of modular synths. Better than nothing.
This kind of simple lists gives a good overall picture of the situation.
For us developers the list should have following info: have source code?
have manuals? have screenshots? have example instrument files?
I think I have collected enough all of that.
BTW, the paper on first interactive graphics system (I.Sutherland's
SketchPad 1963) gives the idea that the drawn circuit diagram could
directly be used as input to the circuit simulators.
Digital modulars have been around as long but I could not find
anything (between 1963-1980) on having a graphical frontend to them.
Of course, I do not have access to many old papers.
Regards,
Juhana
=============================================================================
Source Graph Script
Name Code GUI UI Author/Notes
-----------------------------------------------------------------------------
AlsaModularSynth Yes Yes No M.Nagorni & F.Adriaensen
AnalogBox No Yes ? ?
Arts Yes Yes No ?
AudioMulch No Yes ? Ross Bencina
BlockCompiler OnHold No Yes M. Karjalainen
Building Blocks No Yes ? MIDI only
CPS No Yes ? Niels Gorisse
Csound Yes No Yes Barry Vercoe
Cmusic Yes No Yes ?
DirectCsound ? ? ? ?
DreamStation No ? ? Audio Simulation
Fugue Yes No Yes ?
Gabriel ? Yes ? ?
Galan Yes Yes ? ?
Gdam Yes Yes ? ?
Harmonizer/Vsig No Yes Yes Eventide
Infinity No Yes ? Sound Quest
InstrumentBuilder No Yes ? Mark Trombino, Csound frontend
jMax Yes Yes Yes IRCAM
JSyn No ? ? ?
Kyma No ? ? Symbolic Sound
LabView No Yes Yes National Instruments
Matlab/Simulink No Yes ? Mathworks
MAX/MSP No Yes ? Cycling '74
Moog Modular V No ? ? Arturia
NMEdit Yes Yes No ?
Nord Modular No Yes No Clavia
Nyquist Yes No Yes R.B. Dannenberg
OASYS No ? ? Korg
OpenMusic ? Yes ? IRCAM
PatchWork ? ? ? ?
PD Yes Yes No Miller Puckette
Pulsar/Scope/Noah No Yes No Creamware
PSK Yes No Yes ?
Ptolemy Yes Yes ? ?
Quasimodo Yes Yes No Paul Davis
Reaktor No Yes No Native Instruments
Reality No ? ? Seer Systems
SAOL Yes No Yes ?
Scilab/Scicos Yes ? ? ?
Sildex/Signal ? ? ? ?
Spiralsynthmodular Yes Yes ? ?
SPT ? ? ? Synthetic Intelligence
Supercollider No ? Yes James McCartney
SynC Modular No ? ? ?
SynthBuilder Yes Yes ? Staccato Systems
Tassman No Yes No Applied Acoustics
Tempest No Yes ? Virtual Labs
Vaz Modular No Yes No STL/Martin Fay
VirSyn No ? ? ?
Virtual Waves No Yes ? Synoptic
Visual Orchestra No ? ? ?
WaveWarp No ? ? Sounds Logical
=============================================================================
Juhana Sadeharju:
>
> Hello.
>
> Below is an unfinished list of modular synths. Better than nothing.
> This kind of simple lists gives a good overall picture of the situation.
>
> For us developers the list should have following info: have source code?
> have manuals? have screenshots? have example instrument files?
> I think I have collected enough all of that.
>
> BTW, the paper on first interactive graphics system (I.Sutherland's
> SketchPad 1963) gives the idea that the drawn circuit diagram could
> directly be used as input to the circuit simulators.
>
> Digital modulars have been around as long but I could not find
> anything (between 1963-1980) on having a graphical frontend to them.
> Of course, I do not have access to many old papers.
>
There was one with a graphical interface:
MusicBox No Yes No David Fahrland
And its from the 64-69 or something, implemented in fortran, had a custom
made graphical interface, and supposedly was very much like Max, only
20 years earlier. The machine was placed at EMS/Sweden.
>From google I only found this information:
http://www.ballade.no/nmi.nsf/doc/art2003100811103357431448
(At the top there is a picture of the machine)
--
rd(a)alphalink.com.au:
>
> Since I think this is really important I will give an example, and from the
> other end of a continuum. I use scheme for most of my music work.
> Scheme has a very sophisticated numerical tower. I might write (->
> "/n_set" 1001 "freq" 440) to set the frequency of an instrument at SC3.
> The OSC encoder encodes values based on their lisp type, 1001 is an
> integer and gets encoded as 'i'. Lets assume that to the receiver the
> frequency argument is a float, here I lose because 440 is an integer. I
> argue that a receiver implemented like that is just wrong, that an integer
> 440 frequency is completely valid, and SC3 thankfully agrees and plays
> the right note.
>
For what scheme implementation are you using? And where can I get what
you are using?
--
> The {jack,jamin,ardour,ladcca} archives at
> http://boudicca.tux.org/hypermail/
> are not down.
No, I realized that. Those archives are a fantastic resource and the only
decent way to access this material, many thanks to the tux folk. I only
meant that people had been reporting bounces from the list server, see
<http://www.eca.cx/lad/2004/01/0416.html>.I missed a thread transfer
from jackit-devel to lad for I think that reason.
Rohan
> OK, interesting - it wouldn't be a huge task, but why is this a good
idea?
> It just seems inconvienient for the recipient and I dont know of any
other
> RPC mechanisms where its allowed (or wanted). In the case of
typetag-less
> messages it would be difficult to handle, you'd have to try to discover
> the type of the argument by inspection. Do you have a link to a
rationale
> for this?
Firstly, from the horses mouth, "non-type-tagged messages [are] totally
deprecated". See
<http://www.create.ucsb.edu/pipermail/osc_dev/2003-November/00032
9.html> and surrounding posts. I don't think you need to even try to think
about possibly considering perhaps partially supporting such things!
Secondly, it is actually no work for the receiver. The receiver says that is
needs a signed 32bit integer and it gets such an integer. It is a little
work for the library. On the other hand it can be a lot of work for the
sender. Domain specific languages often do not implement full C like
numerical towers, a signal processing language could easily only
implement floating point numbers, Lua famously has only double
precision floating point numbers, and lots of people use Lua.
Since I think this is really important I will give an example, and from the
other end of a continuum. I use scheme for most of my music work.
Scheme has a very sophisticated numerical tower. I might write (->
"/n_set" 1001 "freq" 440) to set the frequency of an instrument at SC3.
The OSC encoder encodes values based on their lisp type, 1001 is an
integer and gets encoded as 'i'. Lets assume that to the receiver the
frequency argument is a float, here I lose because 440 is an integer. I
argue that a receiver implemented like that is just wrong, that an integer
440 frequency is completely valid, and SC3 thankfully agrees and plays
the right note.
However if you disagree and say that I should write the literal as a float
then that makes scheme a hopeless language to work in, 440.0 is still
an exact integer, I need to write #i440 to get an inexact integer. But the
situation is far worse, if I write (* m 1.5) this seems like it should make
an inexact value regardless where m arrives from, however scheme
knows that (* 0 1.5) is an exact zero and I lose again, it may even know
that (* 2 1.5) == (* 2 3/2) == 3, an exact integer . Forcing a user to _very_
carefully annotate _all_ code that might get sent as an OSC packet
_only because_ the OSC receiver cannot accept exact integers is not
going to work, I just won't be able to work with the process. SC3 gets
this very right, as usual, and in fact allows:
(-> "/n_set" #i1000 (exact->inexact 0) 440)
The node and index values at SC3 are syntactically integers (the index
can also be a string name that maps to an integer), and the argument is
syntactically a float, but it accepts floating point encodings of integers
and integer encodings of real values. SC3 does it like this, QED :)
> I agree that combining the verb and subject seems a little odd, but that
> is the sitatuion in the web services world too - when neccesary they
get
> round it by adding a verb argument eg ("/my/path", "verb", ...), which is
> a useful cnvention but its not neccesary to set it in stone.
I think the real question is, does anyone really want to do pattern
matching on the operator? I have never seen a convincing example. It
would introduce all sorts of really strange sequencing issues to start
with... The pattern matching people seem to like is usually of the form
("/instr[1-4]/freq" 440), not ("/instr1/{freq,ampl}" 330). If you restrict the
matching to the subject, make the subject an argument, and make the
operator the OSC address then the OSC dispatch mechanism can be
reasonably efficient, which matters in RT synthesis environments, and
people who want RE descriptors for subjects can do that without
imposing an onerous burden on the core dispatch mechanism. And it
looks better! In fact it looks comfortingly like lisp, ("/freq" "/instr[1-4]" 550)
:-\
> > * not allocate any memory or call any other non-RT safe procedure
> This one is inherantly not possible, youre doing i/o operations.
Well actually it is only doing the byte encoding. SC3, being dragged out
for yet another example, allows users to link in the synthesis engine and
push OSC packets directly onto a queue, thus avoiding any IPC
operations but still using an identical communication protocol. For the
liblo case you are of course correct, but the temporal behaviour of the
encoder/decoder can be pretty predictable.
> I've always been more of a strongly-typed guy :)
Me too, we schemers all are, we just think that an exact integer is a real
number :)
Regards,
Rohan
anyone got any idea what is wrong with it? i just got a notice from
lists.sf.net postmaster saying my message to it could not be delivered
and was delayed for an unknown reason...
ian
