[PD] pdlv2: generate lv2 plugins from pd patches

Alex x37v.alex at gmail.com
Mon Apr 11 18:52:46 CEST 2016


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 at 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 at lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20160411/80b10026/attachment.html>


More information about the Pd-list mailing list