Hi All, Does anybody know how to solve that one (see below)? I found it posted awhile ago but (it seems that) it didn't get any reply. Now I'm having the same problem. Did anybody find a way around that? Any thoughts are very welcome. Cheers!
Pd-message abstraction creation doesn't start the audio within the abstraction
Okay, another bug using the Pd messages to create objects.
If you place an abstraction within a patch using a >obj x y
abstraction| message, the audio for the abstraction doesn't actually function until you connect two tilde objects within the abstraction; only then does it magically come to life.
Thoughts?
hmm, i don't know. are you using a recent version of pd?
i have dynamically created audio abstractions with no problem.
hi
afaik, when you create an abstraction, containing audio objects, the dsptree doesn't get automatically updated.
either:
you turn off/on pd dsp i.e. with [; pd dsp 0, dsp 1(
or create an other audio object and delete it.
or as you found out: connect two audio objects.
eni
Tuti wrote:
Hi All, Does anybody know how to solve that one (see below)? I found it posted awhile ago but (it seems that) it didn't get any reply. Now I'm having the same problem. Did anybody find a way around that? Any thoughts are very welcome. Cheers!
Pd-message abstraction creation doesn't start the audio within the abstraction
Okay, another bug using the Pd messages to create objects. If you place an abstraction within a patch using a >obj x yabstraction| message, the audio for the abstraction doesn't actually function until you connect two tilde objects within the abstraction; only then does it magically come to life.
Thoughts?
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
what about something like sending a value to the inlet of an audio arithmetic object? would that update the dsptree?
i'm wondering why the audio in my abstractions is working, because i don't think i am doing any of those things.
Hi, Thanks for the reply! I am using Pd version 0.40.3-extended (for Mac OS X 10.5), and, sure enough, pd audio engine does not start at abstract creation time. Here attached are two pd files to illustrate this problem. When you open "test.pd" it will run the abstraction "sine.pd" with the argument 440. If you enable the audio engine, it will generate a sinewave whose frequency is the argument (e.g. 440). Now, if you create a new one, with another argument, say "sine 550" it will NOT generate a new sinewave (together with the sine 440) UNTIL you select/deselect it or tun on/off the audio engine. How to solve that?!? Thanks! Tuti
On Sat, Apr 18, 2009 at 12:23 PM, hard off hard.off@gmail.com wrote:
what about something like sending a value to the inlet of an audio arithmetic object? would that update the dsptree?
i'm wondering why the audio in my abstractions is working, because i don't think i am doing any of those things.
Hm,
worked quite ok here.
And i dont quite understand. Does it bother you ? Dou you consider it
a bug ?
Or are you asking, because you want to know how the dsptree is updated ?
Cheers Luigi
Am 18.04.2009 um 17:56 schrieb Tuti:
Hi, Thanks for the reply! I am using Pd version 0.40.3-extended (for Mac OS X 10.5), and, sure enough, pd audio engine does not start at abstract creation time. Here attached are two pd files to illustrate this problem. When you open "test.pd" it will run the abstraction "sine.pd" with the argument 440. If you enable the audio engine, it will generate a sinewave whose frequency is the argument (e.g. 440). Now, if you create a new one, with another argument, say "sine 550" it will NOT generate a new sinewave (together with the sine 440) UNTIL you select/deselect it or tun on/off the audio engine. How to solve that?!? Thanks! Tuti
On Sat, Apr 18, 2009 at 12:23 PM, hard off hard.off@gmail.com wrote:
what about something like sending a value to the inlet of an audio arithmetic object? would that update the dsptree?
i'm wondering why the audio in my abstractions is working, because
i don't think i am doing any of those things.<sine.pd><test.pd>_______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
------->>>>>>>>>>----------------->>>>>>>>>>>>-----
Dipl-Toning.(FH) Luigi Rensinghoff mobil: 0177-5412191 skype: gigischinke luigi.rensinghoff@freenet.de
On Sun, 2009-04-19 at 00:23 +0900, hard off wrote:
what about something like sending a value to the inlet of an audio arithmetic object? would that update the dsptree?
i'm wondering why the audio in my abstractions is working, because i don't think i am doing any of those things.
afaik, it's only the newest dynamically created tilde-abstraction, that is _not_ part of the dsp-tree. if you generate 3000 abstractions dynamically, you won't notice the one, that is missing.
i hope, someone with insight into the pd-code can confirm this: i experienced, that turning dsp off _before_ dynamically create abstractions, and turning dsp on again after it, is much faster. i assume (someone please correct me), this is because as long as dsp is off, the dsp tree isn't updated at all, even if tilde objects are created. however, when it is running, it will get updated on the creation of every instance, which makes it so slow. when it's off during the creation and turned only after, the dsp-tree will be only update once.
this is why all my dynamic patches do a [t b b b] with the following order:
- [; pd dsp 0(
- create all the instances dynamically
- [; pd dsp 1(
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
Hi, that scheme will work only to turn on the newly created (and muted) abstractions. however, still there will be a "click" and/or audio interruption as you do the "pd dsp 0; pd dsp 1;" trick. I seek a smooth solution (i.e. as the abstractions are created, their sounds come to life, ... no clicks, no hiccups). Cheers, Tuti
On Mon, Apr 20, 2009 at 6:52 AM, Roman Haefeli reduzierer@yahoo.de wrote:
On Sun, 2009-04-19 at 00:23 +0900, hard off wrote:
what about something like sending a value to the inlet of an audio arithmetic object? would that update the dsptree?
i'm wondering why the audio in my abstractions is working, because i don't think i am doing any of those things.
afaik, it's only the newest dynamically created tilde-abstraction, that is _not_ part of the dsp-tree. if you generate 3000 abstractions dynamically, you won't notice the one, that is missing.
i hope, someone with insight into the pd-code can confirm this: i experienced, that turning dsp off _before_ dynamically create abstractions, and turning dsp on again after it, is much faster. i assume (someone please correct me), this is because as long as dsp is off, the dsp tree isn't updated at all, even if tilde objects are created. however, when it is running, it will get updated on the creation of every instance, which makes it so slow. when it's off during the creation and turned only after, the dsp-tree will be only update once.
this is why all my dynamic patches do a [t b b b] with the following order:
- [; pd dsp 0(
- create all the instances dynamically
- [; pd dsp 1(
roman
Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Mon, 2009-04-20 at 11:33 -0300, Tuti wrote:
Hi, that scheme will work only to turn on the newly created (and muted) abstractions.
hm.. i thought, that is what you want....
however, still there will be a "click" and/or audio interruption as you do the "pd dsp 0; pd dsp 1;" trick. I seek a smooth solution (i.e. as the abstractions are created, their sounds come to life, ... no clicks, no hiccups).
i understand. probably i should add, that dynamically creating abstractions is by no means realtime/clickfree safe, since pd wants to process everything in zero time. if a certain task takes more time than the latency you set in the audio menu, you'll get a click/dropout. in theory (all the theory applies, when you record to a soundfile, for instance), you can create as many abstractions in no time without clicks. the same goes for turning dsp on and off.
now, that you mention your problem, i remember, that i once measured the (real) time it takes to turn dsp on with pd on a mac and i was impressed that it takes around 300ms or so. on linux, i am pretty much used to the approach i described in my previous mail and it works out very well (at least, if the latency is not too low). at least, i experienced creating abstractions dynamically without dropouts.
now, i wonder you probably are on a mac. if so, could you probably tell us, what time you measure with the attached patch?
@all why is turning dsp off and on taking so much time on OS X?
roman
On Mon, Apr 20, 2009 at 6:52 AM, Roman Haefeli reduzierer@yahoo.de wrote:
On Sun, 2009-04-19 at 00:23 +0900, hard off wrote:
what about something like sending a value to the inlet of an audio arithmetic object? would that update the dsptree?
i'm wondering why the audio in my abstractions is working, because i don't think i am doing any of those things.
afaik, it's only the newest dynamically created tilde-abstraction, that is _not_ part of the dsp-tree. if you generate 3000 abstractions dynamically, you won't notice the one, that is missing.
i hope, someone with insight into the pd-code can confirm this: i experienced, that turning dsp off _before_ dynamically create abstractions, and turning dsp on again after it, is much faster. i assume (someone please correct me), this is because as long as dsp is off, the dsp tree isn't updated at all, even if tilde objects are created. however, when it is running, it will get updated on the creation of every instance, which makes it so slow. when it's off during the creation and turned only after, the dsp-tree will be only update once.
this is why all my dynamic patches do a [t b b b] with the following order:
- [; pd dsp 0(
- create all the instances dynamically
- [; pd dsp 1(
roman
Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
just a sidenote, but you do know about [switch~] to turn off audio processing in a subpatch/abstraction, right?
i used to have a patch that had about 3000 dsp building blocks (oscillators, filters, waveshapers, eq, effects, etc), and the patch just switched on each part when it was called. in this way everything was loaded at startup, and pd didn't need to create any new objects in realtime.
i just had to be careful with blocking messages from going into [vline~] while the patch was switched off, because they started to make cumulatively longer and longer queues that got completely re-written every time a new message was sent. this was a known issue last year, so maybe it has been fixed for newer versions of pd? i still treat vline~ with caution though, just to be safe.
On Fri, 2009-04-24 at 10:32 +0900, hard off wrote:
just a sidenote, but you do know about [switch~] to turn off audio processing in a subpatch/abstraction, right?
i used to have a patch that had about 3000 dsp building blocks (oscillators, filters, waveshapers, eq, effects, etc), and the patch just switched on each part when it was called. in this way everything was loaded at startup, and pd didn't need to create any new objects in realtime.
yeah, that approach should be preferred, before any dynamic creation approach, i'd say. the process of switching on and off subpatches and abstractions shouldn't eat very much cpu time.
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
-
Enrique Erne -
hard off -
Luigi -
Roman Haefeli -
Tuti