[PD] groove machine how to: keep metro and a loop in sync

[Filippo Beck Peccoz]

Thank you Funs for pointing the reply-all thing out, sorry! Now sending to the whole list :)

I'd be happy to keep tabplay for this since it seems solid and easy to work with, but will have to look deeper into the phasor~ solution, it looks very interesting.

Brian, thanks for your suggestions, and here is the patch with a test loop.

https://fbpserver.dyndns.org/pydio/data/public/366c84.php

It's messy but I commented a bit to show the way- I'm still thinking about how to integrate some sort of dynamic "difficulty level" that gradually introduces longer stretches of silence, but that is not "hardcoded" like it is here.

After a while, the fade kicks in just a tad early, it seems to me. The basic functions are there, but it's weird that it seems to slide a bit. Or am I going crazy? :)


Cheers,

Filippo


Filippo Beck Peccoz
Game Audio

www.fbpsound.com
Twitter: @fbpsound
Skype: fbpsound
Mobile: +49-(0)1520-4004143
Studio: +49-(0)89-80033204
Fax: +49-(0)89-99752164




On Jan 13, 2014, at 7:22 PM, Brian Fay <ovaltinevortex at gmail.com> wrote:

> I'm not super-familiar with the guts of Pd's scheduling system, but I think that if one metro object outputs a bang to separate tabplay~ objects, both should start playing at exactly the same time. 
> 
> While using line~ or phasor~ can lead to more robust samplers (allowing you to adjust playback speed, etc.), I think tabplay~ should be perfectly adequate for this patch.
> 
> Filippo, it would help us to see your patch and the samples you are using, so that we could get a better idea of how the loops are getting out of sync.
> 
> -Brian
> 
> 
> On Mon, Jan 13, 2014 at 12:45 PM, Funs Seelen <funsseelen at gmail.com> wrote:
> 
> Hi Filippo,
> 
> You're welcome.
> 
> You probably forgot to reply-to-all, but I added pd-list to the conversation. I hope you don't mind, but I do this ...
> a) to prevent ten people to answer the same question, not knowing that nine others are or have been spending time to do exactly the same, and
> b) for the archive. It's annoying if you have a problem, search the web, and do find your question, but not the answer, since it is not made public.
> 
> On Mon, Jan 13, 2014 at 5:48 PM, Filippo Beck Peccoz <mail at fbpsound.com> wrote:
> Hi Funs and thanks a lot for the message! Sorry if I'm launching noob questions at you, but so far I've only used a tabplay~ object and a metro with a set bpm, and triggered both of them at the same time- this is obviously not ideal..although it "almost" works the fade into and out of the drum loop should be perfectly timed, especially for this kind of application.
> 
> I am, however, a little lost as to how extrapolate bar/beat information from the objects you suggested. I'm sure it's super easy and I'm missing something obvious. Why do you put the 1000 in the message that goes to the line object?
>  
> I assumed you were reading the table with [tabread~] or [tabread4~]. For looping purposes it is common to use [phasor~] in combination with one of these two. If the loop should last 1 second (1000 ms) its frequence should be 1 Hertz (cycle per second). So the equivalent for the argument `1' for [phasor~] would be `1000' (milliseconds) for [line~]. Translation is done using the following function: y = 1000 / x, where x is the length of the time interval in ms and y the frequency in Hz (note that x = 1000 / y). This one second sample was just an example. [soundfiler] outputs the length of your sound sample in dsp samples.
> 
> I don't understand what you mean by `bar/beat information', for I can't precisely imagine what you are building.
> 
> Regards,
> Funs
> 
> 
> _______________________________________________
> Pd-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20140113/828767f8/attachment.htm>