Hi list,
I've made a patch that loads a sample and, when you press the "b" key, it launches it. Till here all ok. When I tried to customise the message that arrives in [tabplay~]'s inlet, using 2 vradios (one for the sample start and the other for the playback duration), I faced a problem that seems to be quite odd.
Whenever I set the value of the start of the sample and trigger a bang, I can see that the value is set.
Whenever I set the value of the playback duration, I have to trigger twise in order to see the value changed.
I attached you the patch (sampler_test.pd) and the abstractions I used to make it to take a look for yourselfs.
Thank you
Tasos
ΓñçóéìïðïéΓ₯ΓΓ΄Γ₯ Yahoo! ΓÑñΓ₯Γ¨ΓΓͺÑôΓ₯ ôÑ Γ₯Γï÷ëçôéΓͺà ìçΓΓ½ ìÑôÑ (spam); ΓΓ― Yahoo! Mail ÀéÑèΓΓ΄Γ₯Γ© ôçà ΓͺÑëýôΓ₯Γ±Γ§ ÀáΓÑôà ðñïóôÑóΓΓ‘ ΓͺÑôà ôùà Γ₯Γï÷ëçôéΓͺþà ìçΓáìΓôùà http://login.yahoo.com/config/mail?.intl=gr
Hi Tas,
I spotted a bunch of little errors in your loopcut abstraction. Hopefuly this will help you.
- Dollar arguments aren't necessary in things
like float boxes, the float takes the value given at its rightmost inlet if a float type is there. No need to "dereference" it, it's not in a list, and even if it were a list with one float becomes a float.
- You didn't need those two floats to store intermediate
values, only one variable is needed in the computation to hold the value of the sample length. If you store intermediate values unneccesarily you must make sure they get banged through. It gets messy and can lead to "races", so only use [f] to store things when you absolutely must.
- You need to study how bangs propagate a bit more.
I know it's not obvious, takes a bit of experience. Basically nothing happens until a leftmost inlet gets a bang. Using [t b f] units to split the bangs from the floats I've arranged it so the start and end list (pair) gets [pack]ed afresh when *either* input is updated.
- Because you probably didn't want the sample to
fire every time you changed a start or length value I've put in an extra temporary list variable just before the output. The [pack] places the list into that via its right inlet each time it recalculates it. It gets sent to the output only when the left inlet gets a bang.
- Note: Your algorithm for getting the start and end
by division has a fault, but I'll leave you to discover that one :) Hint: If you were writing in C you would be seeing a lot of floating point errors (divide by zeros)
On Mon, 7 Aug 2006 00:33:47 +0100 (BST) Tas Pas tprotopgr@yahoo.gr wrote:
Hi list,
I've made a patch that loads a sample and, when you press the "b" key, it launches it. Till here all ok. When I tried to customise the message that arrives in [tabplay~]'s inlet, using 2 vradios (one for the sample start and the other for the playback duration), I faced a problem that seems to be quite odd.
Whenever I set the value of the start of the sample and trigger a bang, I can see that the value is set.
Whenever I set the value of the playback duration, I have to trigger twise in order to see the value changed.
I attached you the patch (sampler_test.pd) and the abstractions I used to make it to take a look for yourselfs.
Thank you
Tasos
______________ Yahoo! __________ __ __________ ____ ____ (spam); __ Yahoo! Mail ________ ___ ________ ______ _________ ____ ___ ___________ _________ http://login.yahoo.com/config/mail?.intl=gr
Hi!
padawan12 padawan12@obiwannabe.co.uk ΓãñÑøΓ₯:
- Note: Your algorithm for getting the start and end
by division has a fault, but I'll leave you to discover that one :) Hint: If you were writing in C you would be seeing a lot of floating point errors (divide by zeros)
Don't worry mate, I knew the division by zero is not applicable (I hope this is not the only problem I have)....
Thank you!
ΓñçóéìïðïéΓ₯ΓΓ΄Γ₯ Yahoo! ΓÑñΓ₯Γ¨ΓΓͺÑôΓ₯ ôÑ Γ₯Γï÷ëçôéΓͺà ìçΓΓ½ ìÑôÑ (spam); ΓΓ― Yahoo! Mail ÀéÑèΓΓ΄Γ₯Γ© ôçà ΓͺÑëýôΓ₯Γ±Γ§ ÀáΓÑôà ðñïóôÑóΓΓ‘ ΓͺÑôà ôùà Γ₯Γï÷ëçôéΓͺþà ìçΓáìΓôùà http://login.yahoo.com/config/mail?.intl=gr
Hallo, padawan12 hat gesagt: // padawan12 wrote:
- Dollar arguments aren't necessary in things
like float boxes, the float takes the value given at its rightmost inlet if a float type is there. No need to "dereference" it, it's not in a list, and even if it were a list with one float becomes a float.
However in loopcut.pd the dollar signs do serve a purpose: You can call the abstraction with arguments like [loopcut 20 500] to initialize the default start and end values.
- You need to study how bangs propagate a bit more.
I know it's not obvious, takes a bit of experience. Basically nothing happens until a leftmost inlet gets a bang. Using [t b f] units to split the bangs from the floats I've arranged it so the start and end list (pair) gets [pack]ed afresh when *either* input is updated.
There still is a bug. ;)
One should *always* get nervous if more than one message connection leaves a single outlet. This is practically always indicating a logic error.
Here two connections come out of the [f] object in your patch. Pd more or less randomly decides which one will act first. It may be, that the one connected to the left [/ ]-object will fire first, then the one to the right [/ ]. In that case, [pack 0 0] will first send a list composed of the new first value but an *old* second value because the second inlet will receive its division result after pack has fired. And that could make your tablplay play backwards.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
On Mon, 7 Aug 2006 09:31:50 +0200 Frank Barknecht fbar@footils.org wrote:
Hallo, padawan12 hat gesagt: // padawan12 wrote:
- Dollar arguments aren't necessary in things
like float boxes, the float takes the value given at its rightmost inlet if a float type is there. No need to "dereference" it, it's not in a list, and even if it were a list with one float becomes a float.
However in loopcut.pd the dollar signs do serve a purpose: You can call the abstraction with arguments like [loopcut 20 500] to initialize the default start and end values.
Ah yes indeed! I always forget that. But, in my defence, it's more like a repression/denial at the horror of overloading $ so much in Pd. :)
- You need to study how bangs propagate a bit more.
I know it's not obvious, takes a bit of experience. Basically nothing happens until a leftmost inlet gets a bang. Using [t b f] units to split the bangs from the floats I've arranged it so the start and end list (pair) gets [pack]ed afresh when *either* input is updated.
There still is a bug. ;)
One should *always* get nervous if more than one message connection leaves a single outlet. This is practically always indicating a logic error.
Aye Frank spot on, what the patch need Tas is one extra [t b f f] to split up that float and make it "deterministic".
-
Frank Barknecht -
padawan12 -
Tas Pas