---
** [patches:#559] Improving PD for multi-instances and multithreading**
**Status:** open
**Group:** feature
**Created:** Thu Sep 10, 2015 10:35 AM UTC by Pierre
**Last Updated:** Thu Sep 10, 2015 10:35 AM UTC
**Owner:** nobody
**Attachments:**
-
[patch.diff](https://sourceforge.net/p/pure-data/patches/559/attachment/patch.diff)
(6.0 kB; application/octet-stream)
2 things that could really improve the development of applications with Pure
Data :
1 - "t_pdinstance*" in the prototypes of the functions "sched_tick()" and
"dsp_tick()". This way, we don't need to call "pd_setinstance" at each dsp tick
so it is thread safe.
(we could have something like "pdinstance_sched_tick(t_pdinstance* x)" and
"pdinstance_dsp_tick(t_pdinstance* x)" to ensure the good working of previous
applications)
2 - "t_pdinstance*" in the structure of the clock. All the clock_new functions
seem to be called in the "creation" methods of the objects. If when we load a
patch and we create objects, "pd_this" is well defined, we can initialize the
reference "t_pdinstance*" of the clock with "pd_this" and later when we'll call
"clock_set" (for example) the clock will use its reference instead of
"pd_this". In this case, imagine that we send a bang to a [delay] in one
instance during the loading of a pacth in another instance, even if "pd_this"
is not the good one, the clock will be added to the clocks list of its instance.
My first mail :
http://lists.puredata.info/pipermail/pd-dev/2015-09/020339.html
---
Sent from sourceforge.net because [email protected] is subscribed to
https://sourceforge.net/p/pure-data/patches/
To unsubscribe from further messages, a project admin can change settings at
https://sourceforge.net/p/pure-data/admin/patches/options. Or, if this is a
mailing list, you can unsubscribe from the mailing list.
_______________________________________________
Pd-dev mailing list
[email protected]
http://lists.puredata.info/listinfo/pd-dev
