Already suggested for your issue tracker to have both of them available for choosing.) It may destroy portable sequence standart but wouldn’t destroy a chord or can transform it to a sequence which is also pretty cool thing to have.
There is now support for Portable Sequences in Darius - soon to be added to the library. It’s a rather unusual sequencer, so its implementation is unusual too: upon copying, it copies only one of all the possible random sequences it can generate.
I took a look how they were implemented in Squinky Labs’ and Impromptu’s modules, and since their code was strongly coupled to their way of doing thing, I wrote my own lightweight portable sequence code. It’s not battle-tested at all yet, and does not cover all the corner cases (favoring cleaning up bad input instead), but it’s short and simple to understand, so it might save time for someone who wishes to implement them.
Hi Aria, welcome to the Portable Sequence club I never took the time to say this, but congrats for all you modules and the cool and original concepts you devlopped!
Very nice. Thank you. Definitely see the value in your implementation code.
My next device is a quantizer that doubles as a chord sequencer, and once again I plan to use portable sequences in a slightly off-label way. Thoughts on my planned implementation?
Right-click on a Scene slot: “Copy scene”/“Paste Scene”. It’s copied to a portable sequence of global length 1.0, every valid note of the scale a note of length 1.0 on the C4 (pitch = 0.0) octave. The fact it’s a portable sequence rather than an internal format is not made explicit by the UI, only the docs.
Click on the keyboard button (ignore the paste button, both buttons will be merged in a single button the final version): “Copy portable sequence” / “Paste portable sequence” (among other options, such as entering chords in lead sheet and roman numeral notation).
On exporting: Global length as long as the last non-empty scenes, so up to 16. Every scale/chord same as above: length 1.0, C4 octave.
On importing: Ignore the global length. Every event with the same start time is grouped, up to 16 groups are imported to scene slots, quantized to the chromatic scale and folded to a single octave.
That looks very sensible to me. Excellent slight-but-comfortable abuse of portable sequences.
Portable sequences have been implemented exactly as proposed above in QQQQ, coming soon to the library.
This indirectly gives compatible sequencers the ability to load chords in lead sheet notation!
This is great. nice work!
Forgot to post here, but here’s a third module family of mine that implements Portable Sequences, and somehow, it implements them as you’d expect rather than being a weird take on the standard.
They are Modulus Salomonis Regis (8 nodes), Modulellus Salomonis Regis (4 nodes) and Modulissimus Salomonis Regis (16 nodes): self-patching, self-modifying sequencers, that are as deterministic or chaotic as you want them to be.
- Copy Sequence: each node has a length of 1.0
- Paste Sequence: imports as many
notesas possible to its nodes, in ascending
startorder, without quantizing them. The user is assumed to understand the implications of it and interested in exploiting this behavior, and there is a separate right-click option to quantize the status of the module to its internal scale if that behavior is desired.
Excellent! I’ve added a mention to the Entrian Sequencers manual where I list the other sequencers that support the standard. I’ve used the phrase “the Salomonis Regis series from Aria Salvatrice” - is that OK? I’m happy to change it to the wording of your choice, and/or to link to your website / manual / VCV library section…?
(And Bruce, I’m listing Seq++ and Seq4x4 from you - is that still correct?)
Anything works! There’s already 5 modules of mine that support it, so you might want to just say “Most of Aria Salvatrice’s collection” unless you wanna update the docs thrice a year haha. If you want to link to something, https://aria.dog/modules/ is the canonical URL.
OK: wording changed, link added, frequent future updates avoided.
Are there currently any trigger / drum sequencers implementing this standard?
I am currently developing a trigger sequencer, and was looking at using this standard, The documentation seems simple to implement, however each track has no clear definition of pitch. While I could simply assign arbitrary values, possibly the corresponding v/oct for the standard midi drum mappings, I would prefer to use the same values as used by others.
I have been looking at the clipboard data from Entrian Drummer from the “Acoustic Drums” module, but this appears not to follow the format shown in the OP, or described in Squinky Labs document. I am new to Entrian Drummer, with only 15 min use I may have missed how to copy portable sequence data.
@Richie will show up soon enough, but I believe that not all Entrian sequencers use that yet, and since drums is one of the older ones… I believe he did implement this on some non-pitches sequencers, but I’m vague on the details It think using arbitrary values would be ok in your instance - you could still copy rhythms around. If you paste a rhythm, all at middle C, it’s pretty easy to move the pitches around in Seq++, and presumably other sequencers. Most of the Impromptu sequencers implement it, although they tend to have the oposite issue - they have pitches but no programmed rhythm.
@Aria_Salvatrice has done some very clever mappings to those sequencers and I think even quantizers?
One representation that might make sense for drums in portable sequences could be to use notes from the GM drum map?
But it seems nobody has realized how to use it yet, haha.
The Entrian Sequencers don’t support Portable Sequences for drum tracks, because we never created a spec for it.
The problem is how to differentiate drum instruments. A drum sequencer in Rack doesn’t necessarily know what drum instrument any given note is triggering. In fact I’m not aware of one that does, except for the very special case of Entrian Drummer having imported a MIDI drum track (not even a released feature yet).
So you end up just having notes on channel 1, channel 2, etc. with no indication of which instrument they’re playing. That’s not terrible, it just means that you have to wire up your trigger outputs the same way as wherever you were pasting from.
But we also face the question of what a “sequence” is. Melodic Portable Sequences are single track polyphonic sequences. They drive a single instrument, and can ask that instrument to play more than one note at once. With a percussion track, is each instrument separate, and so you’d copy/paste a Portable Sequence for the kick, then a different sequence for the snare, and so on, or is a whole drum kit effectively one “instrument” from the point of view of a Portable Sequence, with each drum instrument on a different channel within that sequence?
Single-drum-instrument Portable Sequences:
- require no changes to the spec; the “pitch” property (and maybe “length”, for a pure trigger sequencer) can just be ignored, or set to known standard values.
- are very simple to understand and use: you copy/paste your kick sequence from A to B, and B now plays your kick sequence.
- allow you to paste one drum instrument into a drum groove without overwriting any others.
- make it a tedious process to copy/paste a complete drum groove from A to B, because you have to do it one drum instrument at a time.
Multiple-drum-instrument Portable Sequences:
- require a spec change, to specify how different channels are represented; not necessarily a new property, but maybe a documented interpretation of the “pitch” property.
- require the user to route their output triggers to the same instruments as where they copied the sequence from (well duh, but maybe not so obvious or easy to achieve across different sequencers).
- make it very quick and easy to copy/paste a complete groove, as long as you have your two sequencers set up compatibly.
When we were initially designing the Portable Sequences spec we did discuss this, and I was in favour of multiple-instrument sequences while Marc was in favour of single-instrument. No obvious right answer there.
Just to muddy the waters further, there’s a separate but related question for Portable Sequences: how should they support multiple tracks? Most of the sequencers that support Portable Sequences (Entrian, Impromptu, Squinky Labs) are multi-track, but you can only copy/paste single tracks using Portable Sequences. It would be nice to support multiple tracks.
That’s a very related question to how to support drum grooves: the answer might be that multiple drum instruments are represented as multiple tracks. I wouldn’t want to come up with a spec for one of those ideas without also spec’ing the other, because they overlap so much.
That was the point at which we said “Designing specs is hard; let’s release what we have.”
Thanks for all the replies, @Richie you replied while I was typing my response, and have covered what I was thinking, but expressed much better.
I think, for now, I shall start by implementing “Single-drum-instrument Portable Sequences:”, as the spec for such is already clearly defined. For now, I shall simply use a pitch of 0.0. If in due course the standard is extended I shall update to follow suit.
I did consider treating the tracks as GM midi, but as already stated above there is no standard layout from numbered tracks to drum voices, and tracks may not be used as drum triggers but for other purposes. This could lead to additional confusion, and I would be guilty of my pet hate of implementing a non-standard, standard.
Great summary Richie!