Re: [Linuxsampler-devel] GUI thoughts

[Josh G. <jg...@us...>]

I have been thinking about this issue for some time now. Its the primary
reason why I started making libInstPatch multi-threaded. My dream is to
have shared multi-peer patch editing (just add a touch of streaming MIDI
and you have yourself a Jam session). SwamiJam is the name I have given
this particular application of Swami. This same idea could be applied to
the GUI-->LinuxSampler problem, I believe.

Some thoughts on GUI(Swami?)/libInstPatch/LinuxSampler:

The way I'm currently thinking of things is that libInstPatch could act
as a patch "server" and would contain the loaded patch objects. Other
"servers" could be set up to synchronize to patch objects residing on
different servers. These "servers" could take advantage of locally
stored patch files (if someone already has the patch that another user
is using, use it - ensuring they are identical could be done via simple
size/name or perhaps MD5 on the parameter data). In the case of the GUI,
I think it needs to have direct access to the patch objects (so anything
it is editing should be locally available, either being served or
synchronized to another machine).


GUI <--> libInstPatch server --> LinuxSampler
           |
           |
           +- Vintage Dreams SF2 (Master)
           +- Lots of Foo.DLS (Slave)
           +- Wide Load.gig

GUI and LinuxSampler would not necessarily be communicating with the
same libInstPatch server, they could be on separate synchronized
machines.

A synchronization protocol then needs to be implemented. It would look
something like so (sudo operations):

ADD <object-data>
REMOVE <object-id>
CHANGE <object-id> <property> <value>

Sample data should probably be handled specially to allow multiple
segments to be sent (rather than all at once). libFLAC could be used for
loss-less compression of sample data.

The question then becomes how LinuxSampler will talk to its local patch
server. LinuxSampler will only really care about presets that are
currently active (i.e. selected on a MIDI channel). I think it would be
too much of a performance bottleneck for LinuxSampler to query the patch
server directly (since the server needs to take into account multiple
peer access, and therefore locking of objects).
Each synth primitive (envelope, LFO, filter, etc) would have its own
internal state data as well as a copy of the parameters from the object
system. Updates to the object system could be queued and synchronized to
LinuxSampler local parameters when they are not being accessed by the
synth.

Anyways, thats how I see it. Does this make sense? Cheers.
	Josh Green