Re: [Linuxsampler-devel] GUI thoughts

[Matthias W. <mat...@in...>]

Hi Josh!

First of all, very interesting idea!

On Wed, Nov 13, 2002 at 12:35:26AM -0800, Josh Green wrote:
> The way I'm currently thinking of things is that libInstPatch could act
> as a patch "server" and would contain the loaded patch objects.

Why is it necessary that those patch server run in their own process?
Why not simply add this functionality to the nodes themself?

> 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).

Hm, would that mean the GUI has to keep a copy of the state data? I
think the state data (modulation parameters, etc.) should only be kept
by the nodes, because those are the ones who need the data always
available.

It would look something like that:

GUI1 <-->libInstPatch.so/LinuxSampler1
           ^                 ^
	   |                 |
           |                 +- Vintage Dreams SF2 (Master)
           |                 +- Lots of Foo.DLS (Slave)
           |                 +- Wide Load.gig
	   |
	   |
	   +---->libInstPatch.so/LinuxSampler2
	   |        ^
	   |        |
	   ...      +-->GUI2

With this scheme, libInstPatch would be a shared library that handles
(to the outside world) the peer communication as well as the communication
with the GUI and controls the state changes to the inside world (sample
engine paramters). The state data would have to be kept one time per
node, no duplication in the patch server and GUI.

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

What's the advantage of this?

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

To me the idea is great and makes a lot of sense ;-).

matthias