Re: [Linuxsampler-devel] GUI thoughts

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

On Wed, 2002-11-13 at 13:16, Matthias Weiss wrote:
> 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.
> 

Thats actually what I meant. I was using the term "server" in reference
to the patch objects being synchronized between multiple clients, I was
assuming that it would be a shared library (it is currently like this).
So, no, the GUI would not need a separate copy of the data.

> > 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?
> 

I think someone mentioned something about being able to edit patches on
one machine but actually sequencing it on another. That was what I was
referring to. Your diagram above is an example of that :)

> > Anyways, thats how I see it. Does this make sense? Cheers.
> 
> To me the idea is great and makes a lot of sense ;-).
> 
> matthias
> 
> 

Thanks for the encouragement. Unfortunately I'm finding that my current
thread implementation with libInstPatch is less than perfect. I'm using
the glib GStaticRecMutex to lock individual patch objects, but just
recently realized that each mutex requires 40 bytes! Since patch objects
consist of samples, instruments, presets, zones etc, there are quite a
lot of them. Thats a lot of wasted space just for a lock. I guess I'll
have to look into some other threading libraries, perhaps just go
pthread or something. The ideal would be a recursive R/W lock. I've seen
these in the pthread library, but I'm not sure if they are recursive. 
libInstPatch is going to need a bit of work. I have faith in the
architecture, but lots of debugging and optimization is in order :)
Cheers.
	Josh Green