[PD] Dynamic patching with audio - review

[Rich E]

Thanks for the insight into more pd internals, although I think I prefer an
approach that does not heavily rely on public pointers floating around, like
pd_newest (it is funny that it is declared in m_pd.h, but then there is a
comment above its implementation that it is a hack, maybe be removed or
redesigned). I chose to use glob_evalfile because it is the closest method I
can find to opening a patch in the 'normal' way.  By the way, if I call
pd_newest after glob_evalfile(), will it give me a reference to the patch?
 I'd try it out, but I don't have my dev machine at the moment.

About namecanvas, there were two issues that I found when I had a system for
dynamically loading/unloading and linking together patches that contained
audio:

1) DSP had to be shut off and then turned back on once the linking was done.
 Sometimes I wouldn't even get audio out of an object until this happened.

2) closing a patch that had audio receivers containing $ variables via the
menuclose message was unstable, and would sometimes crash pd.

I didn't ever get to the bottom of these issues, but from what I understand,
[namecanvas] doesn't handle deallocation too well.  I lost all this code
anyway, so the new approach I am using for patch maintainence is through
libpd and an object oriented language (objective C at the moment, although I
think I would prefer python for running pd on a laptop/desktop).  It is just
really nice.

Cheers,
Rich

On Mon, Mar 21, 2011 at 8:30 AM, Mathieu Bouchard <matju at artengine.ca>wrote:

> On Sun, 20 Mar 2011, Rich E wrote:
>
>  Dynamic patch loading/unloading (not dynamic patching) could also be done
>> directly in a pd external, provided the following small patch is accepted (:
>>
>> http://sourceforge.net/tracker/?func=detail&aid=3189135&group_id=55736&atid=478072
>>
>
> In the meanwhile, a simple workaround is to access the canvas_list global
> variable and walk the linked list of canvases to figure out what has been
> added. Sounds like a hack but is much faster than instantiating an object
> from the linked-list of at least two hundred or thousand names in
> pd_objectmaker.
>
> Besides, loading a patch with glob_evalfile is not the only way to load a
> patch. You can also load it through pd_objectmaker by pretending that it is
> an abstraction. Then you pick up the pointer using pd_newest(). In that
> case, however, don't bother looking in canvas_list, it's not there.
>
> Once you have a canvas pointer, you can find the $0 easily. It involves
> using a private interface that you can have by copying a struct definition
> from pd's source code in the same manner that several externals already use.
> Right after that, ce_dollarzero is yours.
>
>
>  Lastly, the $0 value that libpd recovers lets you send signals or messages
>> to a unique patch, without the need of [namecanvas] - a method that causes a
>> bag full of problems in itself when it comes to dynamic patch
>> loading/unloading.
>>
>
> I'm not sure I understand. What are the problems with [namecanvas] ?
>
>  _______________________________________________________________________
> | Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20110322/a4104fb1/attachment.htm>