Hi Frank, I studied your patch and I substituted the [delay] with [pipe], but, honestly, I wasn't able to find anything wrong there! I also checked by comparing one of the delay-based metros and a proper [metro] of the same speed with timer and they run at the same speed. (see my attached patch). Am I missing something?
Thanks,
Libero
Date: Thu, 27 Dec 2007 18:49:10 +0100 From: Frank Barknecht fbar@footils.org Subject: Re: [PD] complex metronomes sequencing problem (Frank Barknecht) To: pd-list@iem.at Message-ID: 20071227174910.GB19623@fliwatut.scifi Content-Type: text/plain; charset=us-ascii
Hallo, Frank Barknecht hat gesagt: // Frank Barknecht wrote:
Maybe you can just make one of the delay-sequencers your master metro, and encode the periods of the other delays as difference values to the period of the master.
Example: You have one master metro at 100. Then you want one metro/delay A run at 101, another one, B, at 102. For the first bang, delay A will come 1msec late, so its delay will be 1msec. The next time, A bangs, it will come 2 msec late, and so on, so A will be n times 1msec late, modulo 101. For metro/delay B this will be (n*2msec) % 102.
Attached is an example for this re-encoding in action. You can use the master position number box in the to left to jump to a certain position. (This is not really a IOI approach anymore, though.)
Ah, sorry. The math and attachement are wrong here, as the metro will interrupt the scheduled bangs in the delays everytime it bangs. I don't have time for a fix ATM, but maybe you find one on your own. ;)
Ciao
Frank Barknecht _ ______footils.org__
Hallo, Libero Mureddu hat gesagt: // Libero Mureddu wrote:
I studied your patch and I substituted the [delay] with [pipe], but, honestly, I wasn't able to find anything wrong there! I also checked by comparing one of the delay-based metros and a proper [metro] of the same speed with timer and they run at the same speed. (see my attached patch). Am I missing something?
Hm, no, maybe I was only a bit confused ...
Btw. attached are some helper abstractions for calculating LCM and GCD, which may be useful to you.
Ciao
Frank Barknecht _ ______footils.org__
Hello,
For a drumbox project, I wanted to parse more than velocity and note parameter to a voice, like pitch, envelope, FX, ... My first idea was about multiplexing all values and parse them into note and velocity input of [poly] object, and with the sound number, retrieve everything from arrays. This works fine but this comes more complicated for storing all the values into a preset file, and the patching is heavy.
Then I tried to use SSSAD instead of multiplexing, the patching became very clear and light, but I went into a scheduling problem.
Each time a drum instrument is played, the instrument name goes to the second inlet of [polypoly], and in my voice abstraction, [set( is trigged to [SSSAD_ADMIN(.
I use the drum instrument name for routing the output of [r SSSSAD].
When different drums are played at the same time, the parameters are mixed together, I couldn't find out a solution for resolving this.
I could work around some footils examples to show this issue through examples...For the moment here is a share of the files I am working on:
Forget it, it was just some usual wrong triggering... Thanks for all the footils...
Patrice Colet a écrit :
Hello,
For a drumbox project, I wanted to parse more than velocity and note parameter to a voice, like pitch, envelope, FX, ... My first idea was about multiplexing all values and parse them into note and velocity input of [poly] object, and with the sound number, retrieve everything from arrays. This works fine but this comes more complicated for storing all the values into a preset file, and the patching is heavy.
Then I tried to use SSSAD instead of multiplexing, the patching became very clear and light, but I went into a scheduling problem.
Each time a drum instrument is played, the instrument name goes to the second inlet of [polypoly], and in my voice abstraction, [set( is trigged to [SSSAD_ADMIN(.
I use the drum instrument name for routing the output of [r SSSSAD].
When different drums are played at the same time, the parameters are mixed together, I couldn't find out a solution for resolving this.
I could work around some footils examples to show this issue through examples...For the moment here is a share of the files I am working on:
http://megalego.free.fr/pd/patko/
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
to avoid the 'rounding errors' problem and also the [phasor~] block accuracy limit, you can use a [metro], [f ]x[+ ], and [vline~] solution.
speed of this virtual phasor is controlled by the value sent to the right inlet of the [+ ] object, and resetting to a new position just requires sending that new position the the [f ] object first, and then triggering the metro to start again.
the values going into the vline object should be: the output of the [f ] object, and then pack the output of the [+ ] object with the speed of the metro (i use 1ms)
anyway...patch is attached to this mail.
only 'downside' is that speed can only be changed within an accuracy of 1ms. but for musical applications, i can't think of any situation where you would need greater accuracy than that.
On Sat, 29 Dec 2007 20:07:23 +0900 "hard off" hard.off@gmail.com wrote:
to avoid the 'rounding errors' problem and also the [phasor~] block accuracy limit, you can use a [metro], [f ]x[+ ], and [vline~] solution.
speed of this virtual phasor is controlled by the value sent to the right inlet of the [+ ] object, and resetting to a new position just requires sending that new position the the [f ] object first, and then triggering the metro to start again.
the values going into the vline object should be: the output of the [f ] object, and then pack the output of the [+ ] object with the speed of the metro (i use 1ms)
anyway...patch is attached to this mail.
only 'downside' is that speed can only be changed within an accuracy of 1ms. but for musical applications, i can't think of any situation where you would need greater accuracy than that.
No problem, that's a great solution because you nearly always want this phasor moving very slowly.
Hi Frank and list, actually in the patch with the delays you sent, there is a problem: every time [mod] sends 0 to the [delay], I get two bangs at the same time as output, the previous one (delayed) and the new one (delay 0) (see attached patch with a minimal example).
I do not know which is the best strategy to get rid of the duplicate bang, do you have any suggestion?
Thanks Libero
-
Andy Farnell -
Frank Barknecht -
hard off -
Libero Mureddu -
Patrice Colet