> OK, I've thought about this some more and I think I agree with
> you now. I'l add type coercion when I have time, should be easy
> enough.
I think a widely used library that does this transparently will make life
better for everyone. I hope the implementation I mentioned earlier can
save you some time :)
> typed APIs. In this case, if we only do conversions between different
> numerical types I dont see that it will hurt, as long as the corner cases
> are handled sensibly.
I don't think you need to worry about this, if the coercion changes the
semantic value, not just the representation or the precision, the sender
is in error. Sending '10.1' to a slot that is semantically an integer should
be undefined, though in practice you get '10'. Receivers need to run
domain checks in any case...
Regards,
Rohan
> an integer in scheme? Couldnt the problem be solved by specifying
> the type explicitly at send time and doing the coercion then? eg:
>
> (-> "/foo" "isf" 100 "hello" 100.0)
That is exactly what would be required and it is not at all good. People
in user space should not have to even know that there are single and
double precision floating point representations in order to set the
frequency of an instrument. Especially not from a language
environment where the distinction does not even exist! And it will afflict
not only Lisps and dialects but SmallTalks and dialects and MLs and
dialects and so on. I don't know the Patcher dialects but I imagine
things would be as bad if not worse.
It loses straight up for variable arity messages, (apply -> "/n_setn" node
0 data-from-somewhere).
And even from C like languages users still need to *remember* for
every OSC message they ever want to send whether '/frequency' is
required as a single or double precision real number, and whether
'/midi-note' is required as a 'c' integer, an 'i' integer, an 'f' float, or a 'd'
double, all of which are reasonable requirements for different
implemntations.
It means that if two synths have a '/global-gain' controller you might need
to format two different OSC packets to tell them to be quiet [one with a 'f'
zero and one with a 'd' zero].
It means that if a synth implementor decides that the '/phase' input really
should be double precision she cannot change the request type from
the library because it will break *every existing user* of her synth! Their
single precision phase values are no longer good enough? Surely at
this point the implementor will probably just fix the library to do type
coercion or find another library...
In the redundant case the coercion adds one integer comparison to the
dispatch path per argument, and thoughtful ordering of the coercion
table should get most common cases in two or three comparisons; it is
not an expensive operation.
And I am still arguing that it is an important aspect of OSC that when a
synth advertises a '/freq' message, users can be confident that sending
it 440, whether encoded as a 32bit or 64bit integer, or as a 32bit or 64bit
float, will likely tune the synth to A440. OSC is in user space, I think it
would be a pity if synths advertised '/freqi', '/freqh', '/freqf' and '/freqd'
messages in an attempt to help users out.
Regards,
Rohan
> 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
