That's a great project. I also want to add lv2 support to Camomile but It seems that this is not a priority for Juce and I'm a lost between the Juce interface and the lv2 SDK.
I think that Dan is right. It's always better to use locks in C++ because this is integrated in the standard library and cross-platform.
Another reason to avoid automatic lock is because most of the time, you want to send messages and process the digital signal jointly. So it would be useless to lock, send the message, unlock, lock, process, unlock. In my C++ interface, all the lock system is implicit and hidden (when I load or delete a patch for example) except for these methods.
In fact, the lock system is just a detail, the "libpd layer" that Dan explained is the most important. In the C interface of Camomile, I use an internal instance system that really manages the multiple instances.
Nevertheless I'm not sure of the necessity of the ring buffers. It seems to me that it brings some confusion on how the internal mechanism works, like if the methods could be called in parallel while in fact the methods must be called sequentially. But perhaps I don't understand very well the good way to use it or the context where this is necessary.
Anyway I 'm glad someone read my email, I thought nobody noticed :)
Question: What the GUI part is supposed to do ? That would be an interface to receive the textual messages normally sent to tcl/tk ? Or that would be an interface to manage the template/structure/scalar system ?
My thoughts about the locks are this: if you're accessing an API with a single instance across multiple threads, sure, you should lock around API calls with that single instance.. but if you have 2 threads each operating on their own, separate instances, a user of the API shouldn't have to worry about locking. As is, with a global instance setting and callbacks with no "user data", this doesn't seem to be the case. Clearly more of a -dev discussion..
BTW Pierre, your question about the GUI, was that targeted at me?
On Sat, Apr 9, 2016 at 6:45 AM, Pierre Guillot guillotpierre6@gmail.com wrote:
That's a great project. I also want to add lv2 support to Camomile but It seems that this is not a priority for Juce and I'm a lost between the Juce interface and the lv2 SDK.
I think that Dan is right. It's always better to use locks in C++ because this is integrated in the standard library and cross-platform.
Another reason to avoid automatic lock is because most of the time, you want to send messages and process the digital signal jointly. So it would be useless to lock, send the message, unlock, lock, process, unlock. In my C++ interface, all the lock system is implicit and hidden (when I load or delete a patch for example) except for these methods.
In fact, the lock system is just a detail, the "libpd layer" that Dan explained is the most important. In the C interface of Camomile, I use an internal instance system that really manages the multiple instances.
Nevertheless I'm not sure of the necessity of the ring buffers. It seems to me that it brings some confusion on how the internal mechanism works, like if the methods could be called in parallel while in fact the methods must be called sequentially. But perhaps I don't understand very well the good way to use it or the context where this is necessary.
Anyway I 'm glad someone read my email, I thought nobody noticed :)
Question: What the GUI part is supposed to do ? That would be an interface to receive the textual messages normally sent to tcl/tk ? Or that would be an interface to manage the template/structure/scalar system ?
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
-
Alex -
Pierre Guillot