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@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@iem.at mailing list
UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list