Hello!
I agree, it will be best to start with something small, but we should think
about the big picture, so we at least create a structure, that can accomodate
the big library.
As to a testing case, I suppose we can start, with something, that is
already there and use one of the DSSI synth. In the basic DSSI package there
are some test cases and they have there OSC sets. Advantages: they are small,
tested, known to be working and designed from the start to be controlled via
their OSC interfaces. I think that's what all DSSI UIs do.
But a good question there: what does the synth developer have to do? If we
strip it down to the very basics: It should be expose parameters over OSC. If
possible in a meaningful way (have nice paths and good names). If the synth
developer is a kind person he also writes a description/mapping file. I think
it would be enough to know the task and type of each parameter, the rest could
be filled in by a volunteer. It shouldn't be dificult, since at that point it
doesn't require creating structures, but just filling in good paths, if they
don't already exist.
If we think about some kind of standardised way to generate the synths OSC
interface from an RDF file or whatever, that should be sepearted after all,
since some synths/apps already come with their OSC interface, which has been
there for some tme and maybe other apps already rely upon it. But such a code
generator thing can only be done, if we are clear about, what we want and need
and what is feaseable for an engie developer. So I think this can really be
moved towards the distant future.
Warm regards
Julien
--------
Music was my first love and it will be my last (John Miles)
======== FIND MY WEB-PROJECT AT: ========
http://ltsb.sourceforge.net
the Linux TextBased Studio guide
======= AND MY PERSONAL PAGES AT: =======
http://www.juliencoder.de
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@xxxxxxxxxxxxxxxxxxxx
http://lists.linuxaudio.org/listinfo/linux-audio-user
