Here is the copy of the help file (rewind $1 gets orange warning "qlist: extra arguments for message rewind".

I've always gone back to the beginning using rewind (no arguments) and then went forwards to the desired cue. Depending on the complexity of the patch, this might be necessary to insure everything is in the right state. "rewind $1" does seem to be broken.

Thanks for your reply--guessing from the lack of others who don't reply :) I guess this isn't much of a problem--or there aren't many people using qlist PERFORMING on stage at the same time.

I know we can rewind to the beginning and step through to the desired cue, but this is highly inconvenient during performance.

One of the short-comings of MaxMSP is it really seems designed for those people who sit by the computer clicking away and not for performers who is controlling computer on stage with their instruments... :(

And I will stop complaining---I can build this "rewind by step" abstraction--just seems so basic, and so lacking... complain complain :):)

Hi, Mari. I think the documentation lies. I don't think the 'rewind' message takes any arguments. Time to put in your feature request (although I don't know if qlist gets much love in the priorities of C74): a 'back (int)' message and a 'goto (time)' message.

Hi Chris! I know, I never used qlist before and now I know why! :) Neither back or goto message works for qlist. Yuck :)

I always use it with the patcher "qlist_control", which is in the "interfacing" tab of the help patch. That works well for me in certain styles of music, and I'm controlling from my instrument. In performance, I only move forwards through cues --- or I have multiple lists that could come in different orders.

I built a patch to rewind - it is for a student who was using the new MIRA, and it was to safe-guard in case qlist miss-triggered or skipped. It's not nice though, that the "rewind $1" doesn't work when it says it does :)

Just to confirm, unlike what the ref says, rewind doesn't take any argument, it just goes back to the beginning without triggering anything.

Bonjour Emmanuel, thanks!

I understand, I solved it by sending t tbbb+uzi etc. into next and rewind and it works... I'm not going to use this object I don't think. There was a visiting prof. here at my festival who was using it, and it seemed attractive to some. qlist seems to be meant for someone sitting at the desk, not someone playing in realtime :)

I have an alternative cue system that I wrote for my Vassar students. It's simple and flexible. There's a global cue number broadcast, and then you just use a VAS.Cue object for every cue you want to make.

VAS.Cue has three outlets: bang on cue (Always), bang on cue (except in jump mode), bang when leaving cue.

The left outlet is for most cues. Pretty straight forward.

The idea for the middle inlet is that if you have some sort of long-running process (say a long ramp in, or a sound file, etc.), you have a way of skipping it when you're trying to rehearse.

The right outlet is for clean-up. It lets you do any necessary state-setting before leaving the cue.

The other object that I use in conjunction with this is VAS.CueGate which is simply a gate that is open for a cue or a range of cues. (depending on arguments) This is handy for mapping analytical data onto sound processing parameters with minimal overhead. So if I want my transient detector to fire off some set of sound files on cue 13, it looks like:

r TRANSIENT (from analysis patch) | VAS.CueGate 13 | p fireSoundFiles

The nice thing about this is that it works even if you're skipping around, and you're not stuck with static mappings from analysis parameters to sound processing from cue to cue.

The cue number just runs off a counter, though you could do it via coll and next if you wanted to run things out of sequence. At some point, I'd like to make something that's a bit more akin to a lighting cue system with decimal cues. (so you can put cue 10.5 between cue 10 and 11 and not have to renumber)

It doesn't do the elaborate timing stuff that qlist does (with the delayed events in the cue); I don't find that very useful as a performer or composer, so I didn't bother with it. If you need to have a cue trigger a delayed event, you can of course use delay. There are other workarounds for multiple events that are pretty simple, but I think having cues that live in Max (and not in a text file) encourages interactivity with students, though YMMV.

Anyways, I can post it if you're interested.

Thanks---since I'm always on stage, I tend to keep any activities that on the keyboard to a minimal. I don't use foot pedals but against my wishes :) some students do, thus this issue.

I have in the past (for someone else's work written for me) created rehearsal schemes, maybe like yours, to skip and "rehearse from here" button which are useful.

I have been directing Future Music Lab in Maine, designed for high-level performers using technology--last night we had our final concert and everything worked (and a student's qlist on MIRA didn't skip :)

https://atlanticmusicfestival.org/the-institute/programs/future-music-lab