I’ve got a sequence in PhraseSeq16 and I would like to transfer it to PhraseSeq32. I have sent the CV from the 16 to the 32 but I’m having trouble getting the gate pattern to transfer.
How do it set things up so that gate off and flams etc are recorded in PhraseSeq32? Do I have to manually set them?
I’ve not used it, but I believe the Impromptu sequencers support the unofficial sequencer standard (along with a few other developers like Squinky Labs) that allows copying and pasting of sequences between sequencers - so should be no problem to do it between the Phrase Seq 16 and 32 I would imagine? Try the copy and paste buttons?
I completely forgot about that and missed it in the context menu. So copying using the portable sequence option does copy the sequence and gates on/off but not the gate type/shape. The main copy and paste buttons don’t seem to work between modules.
Yeah the “standard” only covers the very basics. Maybe @marc_boule could figure out a way to also support a proprietary copy/paste that would work for this application? Here’s the “standard”: https://github.com/squinkylabs/SquinkyVCV/blob/main/docs/clipboard-format.md
I guys, I guess I could perhaps just add the extended gate info into my portable sequence copy/paste mechanism, since anyone implementing the standard probably already simply ignores anything they don’t recognize? I don’t know if this would be a polite way of doing it, but I think it would work.
Entrian Sequencers will ignore any unknown property in a portable sequence, so adding your own extension properties would have no effect there. You could add a new top-level structure, or add custom note properties.
Awesome, thanks for chiming in Richie! 
same here. You would really need to go out of your way to do anything but that (enumerate all properties, barf on ones you don’t know).
That said, the “best” think would be to have portable sequence and proprietary side by side, like in the “spec”:
{ “squinkylabs-stuff”: “hello”, “vcvrack-sequence”: { “notes”: [ ], “length”: 1 }, }
I think what you are proposing is just fine, and will get a good thing. I think when we were working on the spec we thought about that case, but I think we decided there wasn’t a super crisp answer, so we punted on it.
that said it perfectly, and it’s true that when we read a data entry in the json, we are asking with a token string, so unless there is a name clash, no bugs should ever happen because of this.
The tricky decision is whether your new properties might be useful to other sequencers. If so, you should name them with general descriptive names; if not, you should maybe prefix them with a vendor prefix to avoid possible future name clashes.
(Marc, you already know this of course, but it’s worth mentioning for the wider discussion.)