That looks very sensible to me. Excellent slight-but-comfortable abuse of portable sequences. 
1 Like
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!
4 Likes
Very cool!
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.
Implementation details:
- Copy Sequence: each node has a length of 1.0
- Paste Sequence: imports as many
notesas possible to its nodes, in ascendingstartorder, 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.
1 Like
so cooll!
1 Like
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?)
1 Like
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?
1 Like
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.
1 Like
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.”
2 Likes
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!
@Squinky or @marc_boule is there an updated link to the standard. The link in the original post is dead.
It might be good to update the original post as well.
I think Squinky posted about it being moved a while ago but I can’t find that thread anymore.
Oh, here’s an “unofficial” link. SquinkyVCV-main/clipboard-format.md at master · kockie69/SquinkyVCV-main · GitHub
Sorry it’s tough to find this stuff.
1 Like
Here’s what can perhaps now be called the official link, after Squinky handed that writeup over to me so that I could host it, so to speak:
3 Likes