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 <guillotpier...@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 > >
_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
