[delay] documents tempo specifiers such as "1 60 permin".

Does [makenote] respect these? It seems not, but maybe I'm missing something.

hjh

@ddw_music I am missing something too......
If [delay 1 60 permin] delays the message arriving at the inlets of [makenote] surely it cannot make the note until the message arrives, and a noteoff has to be scheduled from that moment too?
David.

@whale-av

My question is simpler than that.

Does the duration inlet of [makenote] only accept milliseconds, or does it do tempo conversion in the same way that [delay] does?

This has nothing to do with [delay] -> [makenote].

hjh

@ddw_music Then I don't think so. It seems [makenote] has had no update since Pd 0.33 (extended was Pd 0.43.3 in 2011) and it still only has velocity and duration in msecs arguments.
David.

@whale-av

Ah, that's unfortunate. So the "tempo" messages were not implemented as a general programming interface and users basically need to roll their own tempo conversion.

I'm tempted to log a bug for this. Time handling would ideally be consistent across all time-related objects in core.

hjh

@ddw_music Pd is not consistent everywhere. This would be a feature request. It is not a bug.

Fair enough -- I did log it (based on a search, it seems that it was never logged before).

In fairness to myself, I did say it would ideally be consistent -- as an ideal, I think it's not easy to dispute that There's plenty of room for Pd to be useful without reaching every ideal.

I went ahead and logged it (and didn't use the word "bug" anywhere, fwiw).

I might end up making a tempo-conversion abstraction, which could be used anywhere.

Side question: Is there anything like a scheduler in Pd? Where, say, "now" is beat 127.6528625 and I want the next note to happen on beat 129.5.

hjh

@ddw_music This quick and untested sketch is a recreation of [makenote] using [pipe]. It should work the same as [makenote], but i don*t know if the behavior is different when the duration is changed and notes are still in the pipe.

So with this it could maybe be possible to add the time conversion you want and have the [makenote] you need. Another object worth looking at might be [text sequence], which has some kind of scheduler build in.

makenote2.pd

@ingox "Another object worth looking at might be [text sequence], which has some kind of scheduler build in."

Yes, I've used that (spent a couple of hours last semester making an abstraction to clean up its output -- that was difficult).

What I mean by a scheduler is a shared time reference for multiple event players, so that they are all coordinated across bars and beats. [text sequence] is many things, but it isn't that. If you start a [text sequence] on a barline, it will stay in time with other [text sequence]s or [metro]s that started on other barlines. The issue is -- how does it know when the barline is coming, to start on time? (SC has TempoClock for this -- you just say aPattern.play(quant: 4) and it will start on the next multiple of 4 beats after the last meter change.)

As a test, I had hacked something up awhile back that was driven by [abl_link~] -- it worked but it was tricky and I'm not sure if it's scalable (because [abl_link~] outputs high-rate control messages).

I guess an abstraction could populate a [value] periodically, and you'd calculate offsets from that. The offsets may be invalid if the tempo changes (which SC's TempoClock handles by waking up the thread upon a tempo change).

hjh

@ddw_music It is often forgotten that [metro] is the Pd metronome and it will take beat length messages though not quite as "musically" as quant for TempoClock.
So bars and beats can be sent separately with two tied [metro] clocks or one and a counter.
Could you run a global [metro] clock that bangs tempo message changes through to [timer] [text] [delay] [qlist] only at bar lines?
It looks as though [delay] and [timer] will update any remaining delay if they receive the message at other times. [text] doesn't say, but might behave the same way? If it does then you could allow tempo changes at any time for more interesting rhythms.
Then you could have a bar "lock/unlock" switch.
The global [metro] could be tied to audio maybe, It looks as though it will take the samp argument just as [delay] does.
David.

@whale-av

It is often forgotten that [metro] is the Pd metronome and it will take beat length messages though not quite as "musically" as quant for TempoClock.

The limitation there is that it necessarily enforces a certain time granularity. (Though, modular sequencers have the same limitation.)

In SC, you can schedule for any floating-point time, on or off a grid. A [metro]-driven clock in Pd could calculate an offset from the preceding grid line; if the granularity is tight enough, it would be reasonably accurate even through moderate tempo changes.

So bars and beats can be sent separately with two tied [metro] clocks or one and a counter.

Or take the modular "clock divider" approach (wherein, after a night's sleep, I see that I messed up the connections out of the [select 1] but I won't bother to fix the screenshot ).

hjh