an easy way might be to put a [bang~] in a subpatch, so that it is triggered
after the [env~ ] objects, and then connect each [env~] to the right inlet
of a [f ]...then you
can bang the floats with [t b b] from the [bang~]
___
Pd-list@iem.at mailing list
hard off wrote:
an easy way might be to put a [bang~] in a subpatch, so that it is
triggered after the [env~ ] objects, and then connect each [env~] to the
right inlet of a [f ]...then you
can bang the floats with [t b b] from the [bang~]
well, but the [bang~] will have the same problem: it
IOhannes m zmölnig wrote:
but of course you proposal to use another source for synching the
outputs is the way to go.
yeah, i kind of realised this one as well...
hm. are all the [~] objects going to trigger before or after all the
message-rate objects? is that much defined? or could there
Damian Stewart wrote:
hm. are all the [~] objects going to trigger before or after all the
message-rate objects? is that much defined? or could there be
interleaved [~] and message-rate object firings? eg an [env~] fires
before a [* ] which is then followed by another [env~]?
well,
Pd's
IOhannes m zmölnig wrote:
now, signal-to-message objects _should_ accept this scheduling, by *not*
sending messages in the dsp callback, but rather schedule them to the
next tick (via a [delay 0])
afaik all _internal_ objects adhere to this.
hm, again.. so, at what point do these invisible
Damian Stewart wrote:
IOhannes m zmölnig wrote:
now, signal-to-message objects _should_ accept this scheduling, by *not*
sending messages in the dsp callback, but rather schedule them to the
next tick (via a [delay 0])
afaik all _internal_ objects adhere to this.
hm, again.. so, at what
Damian Stewart wrote:
IOhannes m zmölnig wrote:
now, signal-to-message objects _should_ accept this scheduling, by *not*
sending messages in the dsp callback, but rather schedule them to the
next tick (via a [delay 0])
afaik all _internal_ objects adhere to this.
hm, again.. so, at what
Damian Stewart wrote:
IOhannes m zmölnig wrote:
now, signal-to-message objects _should_ accept this scheduling, by *not*
sending messages in the dsp callback, but rather schedule them to the
next tick (via a [delay 0])
afaik all _internal_ objects adhere to this.
hm, again.. so, at what
what's the order of execution for signal~ objects that output messages (eg
env~)?
eg:
[...~]
|
[env~]
|
[print 1]
[...~]
|
[env~]
|
[print 2]
which will get printed first?
cheers
d
--
damian stewart | skype: damiansnz | [EMAIL PROTECTED]
frey | live art with machines |
Damian Stewart wrote:
what's the order of execution for signal~ objects that output messages (eg
env~)?
eg:
[...~]
|
[env~]
|
[print 1]
[...~]
|
[env~]
|
[print 2]
which will get printed first?
depends on the order of execution in the signal objects.
thus it is usually
Damian Stewart wrote:
what's the order of execution for signal~ objects that output messages (eg
env~)?
which will get printed first?
It's undefined, unless you define it with subpatches with signal cords
between them (which don't need to carry meaningful data, just the
presence of a signal
Hallo,
Claude Heiland-Allen hat gesagt: // Claude Heiland-Allen wrote:
this is documented somewhere, i think in a flanger example...
It's in doc/3.audio.examples/G05.execution.order.pd and more verbose
in The Book Every Pd User Can Learn A Lot Of (tm):
Am 25.09.2008 um 14:22 schrieb IOhannes m zmoelnig:
unless you use order-forcing.
... which i have never heard of... do you mind to elaborate?
thanks, gr~~~
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -
Thomas Grill wrote:
Am 25.09.2008 um 14:22 schrieb IOhannes m zmoelnig:
unless you use order-forcing.
... which i have never heard of... do you mind to elaborate?
i'm sure you did.
it's the same technique claude had in mind and which is described in
3.audio.examples/G05.execution.order.pd
Am 25.09.2008 um 15:22 schrieb IOhannes m zmoelnig:
Thomas Grill wrote:
Am 25.09.2008 um 14:22 schrieb IOhannes m zmoelnig:
unless you use order-forcing.
... which i have never heard of... do you mind to elaborate?
i'm sure you did.
it's the same technique claude had in mind and which is
15 matches
Mail list logo
