For timed sequencing, [auto( -> [text sequence] is the most convenient.

But... how do you get access to the wait times?

The 'wait' outlet is active when [step(-ping, but seems not for auto mode. So if I want to generate note-offs after 70% of the wait time, there's... no way without stepping? Or hand-writing all the note-off delay times? (These students' eyes will glaze over for the step+delay logic... I really want to use auto mode...)

hjh

@ddw_music I think -w 1 is the simplest to understand..... with the first value of each line setting the wait time as in the older [qlist]
So [text sequence thesequence -w 1]
Then use feedback to the [bang( message to set the percentage....... and be able to change it....
That will give you a "variable" auto and should be easy to understand for your students.
Or use the [tempo( message?
If you have no wait times in your list you can still set a variable wait time in a similar manner by sending it into the delay.
David.

@whale-av Ended up with this. Getting status toggles and looping into it, so that it "just works" from the user's perspective, took a bit of effort.

hjh

Ah, one mistake: the right outlet of [route] isn't connected to [text].

Took a bit to figure out that [tempo( messages should be directed to the [delay] rather than the [text] but it seems to be working quite well now. And added a creation argument for the looping flag.

[seq-hjh.pd]

Reuploading because the old one has a [print] left in by mistake: seq-hjh.pd

hjh

Hm, what's the best way to handle this?

Bang --> [text sequence] outputs a data point (left outlet) and then the wait time until the next event (middle outlet).

Now let's say I want to play this note (the most recent data point) for 50% of the wait time until the next event, let's say, using [makenote]. So I need to multiply the wait time by half and put it into [makenote]'s right inlet first, before passing the note number into the left inlet. But the wait time comes out of the middle outlet second.

So I suppose it needs to be data --> list box cold inlet, then the wait time --> [t b f] to push out the wait time first and then bang the data list? That'll work assuming it's always alternating wait, data, wait, data (and the first output value will be invalid, have to suppress it).

Or is there another trick?

A concrete problem here is that you don't know how long the last event would be. I was prepared to accept pd's design here, but I think e.g. SuperCollider's concept of an event, binding up arbitrary data with a time delta until the next event, is better (whereas [text sequence] binds the data to a wait time preceding the data).

hjh

@ddw_music .............?

@whale-av but the problem is... your visual arrangement assumes that the sequencer outputs a note first and then a wait time (right to left ordering). But [text sequence] does the opposite -- the wait time comes first.

So your wait time will trigger the [pack] immediately, but the note data haven't been put into the list yet. So the initial note number is uninitialized data = a bug.

Can't do it that way.

hjh

@ddw_music Sorry..... you said wait comes second...
David.

@whale-av Ah, right -- I didn't explain clearly. So maybe it's time to "begin at the beginning."

Where I'm coming from: In SuperCollider, it's easy to express the idea of an event now, with a duration of 100 ms (time until the next event), with the gate open for the first 40% of that time:

(midinote: 60, dur: 0.1, legato: 0.4)

... producing control messages (0.04 is indeed 40% of 0.1 sec):

[ 0.0, [ 9, default, 1000, 0, 1, out, 0, freq, 261.6255653006, amp, 0.1, pan, 0.0 ] ]
[ 0.04, [ 15, 1000, gate, 0 ] ]

That is, an event is conceived as a span of time, with the action occurring at the beginning of the time span.

By contrast:

reset: line 0
reset: bang
w: 100

What is the data point that should occur at the beginning of this 100 ms span?

OK, never mind, continuing...

bang: bang
d: 60
w: 200

Ohhhh... it's really 200 ms for midinote 60. But you didn't know that at the time the data came out of the left outlet. Normally we assume right to left, but at the moment of requesting the next data from the sequencer, it's actually left to right.

bang: bang
d: 62
w: 300
bang: bang
d: 64

And... (the really unfortunate flaw in this design) -- how long is 64's time span? You... don't know. It's undefined. (You can add a duration without a data value at the end -- and I'll do that for the rest of the examples -- but... I'm going to have to explain this to students in a couple of days... if there are any clever ones in the lot, they will ask "Why is this note's duration on the next line? Why do we need an extra line?")

Let's try packing them:

reset: line 0
reset: bang
bang: bang
notedur: 60 100
bang: bang
notedur: 62 200
bang: bang
notedur: 64 300
bang: bang
notedur: 64 400  (this is with "400;" at the end of the seq)
bang: bang

Now, that "looks" like what I said I wanted -- but it's misleading, because the actual amount of time between 60 100 and 62 200 is 200 ms. The notes will be too short.

reset: line 0
reset: bang
notedur: 64 100  -- "64" is leftover data
bang: bang
notedur: 60 200  -- OK, matches sound
bang: bang
notedur: 62 300  -- OK
bang: bang
notedur: 64 400  -- OK
bang: bang

So the last version is closer -- just needs a little logic to suppress the first output (which I did in the abstraction).

Then, to run it as a sequence, it just needs [t b f f] coming from the wait outlet, and one of the f's goes to [delay] --> [s go]. So the completed 40% patch (minus first-row suppression) looks like this:

I guess part of my point is that it took me almost two hours to work this out yesterday... but sequencing is a basic function of any music environment... isn't there some way to make it simpler to handle the very common musical conception of a note with a (subsequent) duration? (Pd already has exactly that conception -- [makenote] -- so, why is the sequencer at odds with [makenote]?)

hjh

@ddw_music I see. Yes, it is not designed for your purpose.
"Why is this note's duration on the next line? Why do we need an extra line?"
Because [text sequence] sets the wait time..... not the duration...... the same if duration is 100%..... but.