What objects for a dynamic cue system?
So for a section of my patch I want to create a cue based system that's dynamic (as in, I can reorder the events easily, and on the fly) and have a variety of event types that can trigger the changes (ie after 2 minutes, or after 100 bangs, or after the linear centroid stays above 2k for 3 seconds, etc..). The 'events' themselves would likely be just a bang (which would select a preset and/or put other changes into effect).
I've never built anything like that before, and it's easy enough to compartmentalize it (the cue list/order vs the triggering mechanism) but I'm sure there's a much better/easier way to do this than what I was planning (just using some gate/switches to handle the 'logic' for transitions, and then maybe like a [pack s s s s s s s] to produce a list of cues, but this path seems very stiff in that if I wanted to restructure something, I'd need to patch). Ideally it would be an interface that I could, before a performance, decide that I want these X cues to happen, and what will advance each cue is Y1, Y2, Y3, and that on the fly I can reset the system, or skip/alter the order as they happen.
So has anyone built something like this? And/or can someone point me to the object(s) I should be looking at.
perhaps you can use a coll for storing these cues and dump them whenever you want ? reset the coll ? ..
or [zl reg] ,[zl group]
if i understand you want to list a few bangs and provide it later ?
Yeah, but I also want to be able to easily determine what cues to do in what order (without having to do a bunch of manual coll entries).
as far as you have them indexed you could provide decissions . what about [zl lockup] ? you can choose which element of the list to release
I'm thinking [coll] will probably be handy - you can name your cues (which will be the 'key' in the coll) and then any data about the cue (settings, etc) can be the data referenced. Reordering is just a matter of asking for a different cue from the [coll]. You should probably also look into the SQLite database in Max, as that would be much more robust for what you want - but a good deal more complex. Essentially you'd set up your cues, and be able to trigger them on the fly, in any order. Making an ordering system could just as easily be another [coll], consisting of "(cue), (time to next cue)" rigged into a timer object of your choosing. But again, the SWLite will be more powerful and give you more options (IE, "cue, trigger type, data (be it threshold for your centroid, number of bangs, milliseconds, etc)")
I may be way off base, because it's 8am and I haven't slept yet.
Hmm, I wonder why this article/tutorial disappeared:
https://cycling74.com/tutorials/data-collection-building-databases-using-sqlite/
I don't know if I need to bring out the 'big guns' of sqlite, but I guess I can try to produce a coll that would act as that performances 'script' (with each cue, trigger type, etc.. filling it) and then just have a mechanism for stepping through it which would trigger each transition type depending on what the coll says.
That still leaves the issue of how to pack/fill the coll. A drag and drop thing would be difficult (for me) to code, and I'm not certain that would be super easy to use. There could be a nested dropdown menu like the iTunes smart playlist criteria, or the Finder advanced search. It could get more particular, but may get visually messy. Hmm.
Rodrigo ? what do you want to drag and drop if may i ask ? :D ... im doing many things with coll . my whole system im currently working on depends on the constant operations ,dumps etc .if i know more about your need i might be able to think with you
edit: you can visualise whats in coll with jit.cellblock ,and even provide some decisions from its UI
ps:your link is working here
That's weird that link wasn't working (for me) a second ago. I'll read through that now.
I don't really want to drag and drop, I'm just trying to think what would be a good mechanism to input/decide this stuff before a performance. Basically I don't want to come out of presentation view or have to edit code at all. I'd want to be able to decide the order of things I would like to happen and what will trigger those changes, but quickly/efficiently. Probably having presets for these 'compositions' too, so I can just fire up and old cue list and go from there.
I've not really built any of the system supporting this yet, so it's hard to picture how to go about it. It will likely be preset based (local and global presets being triggered) and that'd be it for the actual 'cues'. The triggering mechanism will be based on a bunch of different types of actions (time, or any number of analyzed events, or both etc..)
that should not be a problem really . you just filling the coll with your "stuff" . you can store a list and index it for your choice . then your conditions of "what triggers what" do the job as you programed it . you really dont need to go for SQ .
If you need help ,i will be back in 40 minutes :/
so im back .
do you know how do you want to determine your order that will trigger out indexed data from the [coll] ? ... you want to make it under the hood or from UI ?
As MuShoo mentioned this can be achieved with another [coll] and you dont need to be afraid to use it :)
If you did not progressed with it yet ,you can write down the conditions you want to make so it will be easy to get on it from there ,as this could be only the part where use of objects would determine that structure implementation . your input here is needed . but if u are already somewhere then happy patching
At the moment I'm building a preset naming/recall section, so I can store/morph presets and be able to individual name them (otherwise this more complicated cue system will be useless if all my cues are called "1", "23", "39". So once I can build preset storage that saves as "The prickly one", "Heavy distortion", "Automatic looper/stutter" I can actually try organizing it.
I definitely want to organize things in UI, as this would be a pre-performance thing.
The actual trigger/transition thing wouldn't work with a coll (I don't think) as otherwise I'd need a coll entry for every possible outcome ("after 2 seconds", "after 3 seconds", "after 156 bangs, and two seconds") unless I'm misunderstanding what you mean.
What I'm picturing for the trigger part is a selection of types of prompts, and then an entry for how many of them (so the first thing would be, seconds, bangs, attacks, exceeding a threshold, and the second thing would be a number). Then perhaps have a conditional argument between two of these types of entries, so xxx AND xxx, xxx OR xxx, xxx THEN xxx.
I can't picture doing something like that with a coll.
I'm guessing the transition would be a bunch of umenus driving switch/gate/counter/sel logic stuff, though it would be hard to do the conditional relationship (and/or/then).
you want [qlist]. 25 years old and it is still amazing. i have had it run massive performances and installations etc flawlessly. you might want the cort lippe patch to go with it.
however, for dynamic reordering of cues etc, rather than rewrite text files on the fly for qlist (which works, but), you need [dict] or [sqlite] - they are very powerful too. and sqlite remarkably simple, don't be fooled by the 'complex'/'big guns' thinking.
coll is no good, as it counts up from index 0 every time you access an index, so response is very slow, especially with large data sets like potentially yours.
of course using all this with pattr is rather powerful, too.
useless opinions, some facts, 2 cents.
I started off by looking at qlist but the help file was quite anaemic and I couldn't figure out if it was what I thought it was.
Is the cort lippe patch online somewhere? I quick googling just pulled up that it's in a book.
Dict looks like the nested menu type of thing I was looking for. I need to poke through the help file as I've never used (or seen) it before. Not actually sure what's even going on in the queries section. But something like that formatting a message with a $1 variable for times/etc.. could feed the machine that then actually does the stuff.
These tutorials for Dict are worth a look,
the cort lippe patch is the one called "qlist_control" in the "interfacing" tab of the [qlist] helpfile. apologies for the oblique reference, i did not realise that it did not actually say it.
dict might be better on reflection. although the benefit of qlist / qlist_control is the ability to easily 'restore state' non-chronologically. although it is complex if the patch setup is big. in fact remembering now, i think there is a big example of this in the cnmat collection. have not looked for a while though.
the great thing about external file methods like dict and qlist, is that you can resequence everything by rewriting the .json / .txt file, without having to modify anything in the patch.
what about just a simple [js cues.js]? That's what I used to sequence lighting/sound/projector cues for a play I helped produce this past spring. By defining functions numbered 0-110 or so, I could 'script' things like lighting fades (using the morphing function of pattr, all I'd have to do is send the starting preset, target preset and a time value for [line] out the appropriate outlets, and presto). Messed around with [coll] a bit before I realized that the ability to script tons of information and specify outlets from one single .js file was the most simple and ideal solution for my purposes.
Your desire to have a more user friendly UI, however, is what still puzzles me in my current projects. Would love to have an "iTunes playlist" like GUI for dragging and dropping files (.txt, .midi, .aif, .mov, what have you) with the ability to re-sort by the different metadata tags and save new playlists on the fly. It seems a lot of forums out there are hinting towards the same thing. Maybe a revamped jit.cellblock is the key?
As in this:
http://cuejs.com
?
Hi GMIX, wondering if you might be able to share your patch, or a part of the java side? I'm looking to script a few simple lighting cues and would greatly appreciate the guidance. Not sure if cuejs.com was once a thing, it seems to be dead now — thoughts? thanks in advance!