Menu
▾
▴
linuxsampler-devel
|
From: Matthias W. <mat...@in...> - 2002-11-11 21:23:43
|
Hi all! I'd like to know your opinion about some thoughts regarding the GUI. As mentioned by Benno and Steve, when linuxsampler will run as a plugin of jackd, it'll be necessary to use some sort of communication mechanism between the plugin and the GUI. While the stability plus and the code cleanness due to the forced separation of engine code/GUI code are very attractive, there are also some difficulties connected with it. I think linuxsampler should also have the ability to create a sample instrument/set. Therefore it will be necessary to edit wave files, set loop points etc. Now the first problem that occures to me: how do I generate the waveview of the sample data when the samples are on one machine and the GUI on the other? Should I pregenerate the sample view data on the plugin machine and send it to the GUI machine? And if I edit the sample, should the edit commands be send over the net to the plugin machine, the plugin calculates the result, obtains the new sample view datas and sends them back? This seems to get really complicated. It also makes an idea of me impossible to imbed an existing wave editor as a component (e.g. as a bonobo component) into linuxsampler. In that case we would not have to reinvent the weel and write the XXX's wave editor but use an existing one (e.g. snd). But AFAIK the existing ones have no capabilities of remote control. matthias |
|
From: Josh G. <jg...@us...> - 2002-11-13 08:34:44
|
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
|
|
From: Matthias W. <mat...@in...> - 2002-11-13 21:20:02
|
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
|
|
From: Josh G. <jg...@us...> - 2002-11-14 06:35:20
|
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 |
|
From: Josh G. <jg...@us...> - 2002-11-16 03:22:30
|
On Fri, 2002-11-15 at 13:18, Matthias Weiss wrote: > On Wed, Nov 13, 2002 at 10:35:51PM -0800, Josh Green wrote: > > > > 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. > > AFAIK there are no r/w locks in the current linuxthread implementation. > I read about plans to include those in connection with the NPT (native > posix threads). > > matthias > What about pthread_rwlock_t (you can see this in /usr/include/pthread.h). I notice that the function prototypes are surrounded by an "#ifdef __USE_UNIX98" which I'm unfamiliar with. I can do a "p sizeof (pthread_rwlock_t)" in gdb with a pthread linked program, so it seems to be available (32 bytes a mutex, not bad I guess). Cheers. Josh Green |
|
From: Matthias W. <mat...@in...> - 2002-11-16 17:43:28
|
On Fri, Nov 15, 2002 at 07:22:35PM -0800, Josh Green wrote: > > AFAIK there are no r/w locks in the current linuxthread implementation. > > I read about plans to include those in connection with the NPT (native > > posix threads). > > > > matthias > > > > What about pthread_rwlock_t (you can see this in > /usr/include/pthread.h). I notice that the function prototypes are > surrounded by an "#ifdef __USE_UNIX98" which I'm unfamiliar with. I can > do a "p sizeof (pthread_rwlock_t)" in gdb with a pthread linked program, > so it seems to be available (32 bytes a mutex, not bad I guess). Cheers. > Josh Green I played around with this when I needed 'pthread_mutexattr_settype' and found out that I had to define #define _XOPEN_SOURCE 600 before the first system include in my code; this will set some other defines in /usr/include/features.h . I have to note that lots of basic types (I guess one of it was size_t) got screwed up so I had to drop it again. Besides, I'd try to use atomic types and atomic read/writes to avoid locking wherever possible. matthias |
|
From: Matthias W. <mat...@in...> - 2002-11-15 21:22:50
|
On Wed, Nov 13, 2002 at 10:35:51PM -0800, Josh Green wrote: > > 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. AFAIK there are no r/w locks in the current linuxthread implementation. I read about plans to include those in connection with the NPT (native posix threads). matthias |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X