Now resizable by grabbing right hand edge - I couldn’t have imagined doing this a week ago lol
New formats added to parser: <Number>Hz and <Number>ct (for cents), both translated to 1v/octave like other pitch formats.
I’m on the hunt for more weird ways to write pitches and/or voltages, let me know what you’ve seen, especially weird esoteric formats.
Removed outdated G for “gate” syntax in presets, default text, etc.
Fixed a bug where some double sharps/flats would not be found because normal sharp/flats within them would be found first, this should probably be something nicer than a lookup table
I use relative harmonic degrees and scale integer intervals 1-7 (1.0-7.0) and (I-VII) for scale intervals (1st,2nd,…,7th) relative to the current diatonic scale. So, my PS-PurrSoftware modules Meander and ModeScaleProgressions can be sequenced for circle-of-fifths chord progressions and scale melody in Meander and chord progressions in ModeScaleProgressions. Actually, the modules accept these intervals in octal-radix interval.octave floating point (decimal) form, so any note in the scale can be so played at (almost) any octave.
There are a few other modules by others that supports this notation on one way or another.
Just to clarify, this allows any of Meander’s (and ModeScaleProgressions) ~85 predefined chord progressions to be played in any mode and root diatonic scale, internally in the modules, or custom progressions can be input into my modules’ “degree” inputs. My modules output these chord degrees for other modules to use. Actual usage details are in my manual. Input can come from a MIDI keyboard or from a Rack CV source but the “gate” degree input is handled differently between keyboard and CV control. (hint, in CV mode, the 1-7 degree is input into my modules’ degree inputs and the adjacent gate input. This is just so that my modules know how to do the conversions.
BTW, the Aaron Static DiatonicCV module can accept the “degree” CV’s input to the “Chord” inport.
Hrm, I do keep thinking about scale degrees (and Solfege), but right now the syntax has no conception of key/mode/time signature/etc. It is similar to a tracker in that way.
Maybe that’s fine though, and that’s just something you toggle on the module itself, and maybe have a new command in the sequence’s syntax that updates the key and/or mode? Or the key and mode could be part of the cell’s value, in a format like <key><mode><degree> or <root>+<interval>? Either way, it also needs to be easily distinguished from plain decimal values and/or note names.
EDIT: On the other hand, you can already do things like use one column for the root/key, do your melody all in octave 4 in another column, and add together their output voltages, maybe also quantizing them or sending to something like Plurm chordscalequantizer. That would be the “modular” way to do it, and does have a certain appeal of “austerity”.
I speculate that it was developed for sharing tunes over usenet and SneakerNet, especially folk tunes. There’s a crapload of repositories of traditional tunes in that format.
I thought about ABC, and someone in the Discord mentioned MML, but since Spellbook is more like a “sequence roll”, a bit like a tracker, they don’t feel like great fits in a context where I want to just step, line by line, through a sequence. Would love to see an ABC or MML player as another module though.
It would be fun if someday we have a text interchange standard for all things music and something like Tipsy could be used for modules to talk to each other. But, a full language is a big chore to support. It is almost a necessity for the standard to support time signatures and thus the sending and receiving modules understand time signature. Not many modules currently handle time signatures and note durations in time signature units such as whole, half, quarter, eighth notes and so forth. My Meander and ModeScaleProgressions modules do understand time signature and note lengths, but it is rare. The modules also have to understand tempo. And, really, the modules have to understand scales and keys for at least the diatonic modes. So, no small task
If we had all of the above, we could consider creating musical scores in standard musical font graphical formats.
I downloaded MuseScore and tried using it as a digital audio workstation, experimenting with VSTs and VCV Rack as instruments in its Mixer. I realized I wanted a way to write sequences that aligned more closely with how I conceptualized them coming from modular, rather than how they’re laid out in sheet music (which serves a different purpose than driving modular voltages). Piano roll editing also didn’t feel quite right, for a similar reason, because I don’t think of most sequences as “notes”.
I also wanted a “plain text” feel, like “Markdown for Music,” focusing on simply writing down the sequence, while supporting as many ways of expressing pitches and voltages as possible.
You mean like MusicXML? it’s widely supported among scoring programs. but IIRC it’s limited to 12T MIDI pitch and I don’t remember if has non-note data…
I spoke briefly with @Jadael about this, but they are most interested in a pure ascii format, so of course neither of these “standards” were of interest.
Letting people copy/paste to the whole sequence in this JSON format (separate from the plain text copy & paste) feels much more doable now actually, and would be a fun way to write sequences in RhythML and then “apply” them to other sequencer modules, instead of “driving” other module.
of course the beauty of the clipboard is that you can put multiple data formats on the clipboard. If you are considering “portable clipboard format” be aware that not that many sequencers support it.
Turns out it was failing to parse flatted notes like Gb4 this whole time because I forgot to account for making sure it was case-insensitive.
In the course of fixing that bug, I revamped the note name parsing so it can handle any arbitrary number of sharp/flat symbols for compound accidentals like G##4 (which would be the same pitch as A4), and added two more accidentals: $ for half sharp, and d for half flat. You can mix and match them freely, so you can get “C sharp and a half” with C#$, or if you do C#b they cancel each other out and you just get C. (The logic is simply: +1 semitone for each sharp, -1 for each flat, +0.5 for each half sharp, -0.5 for each half flat.)
EDIT: Is everyone happy that B#4 gives you a pitch (1.0 volts / C5 / 523.25Hz) that one would normally consider as being “in octave 5”, despite the number “4” being explicitly present?
Alright, now this is the actual candidate for a library release. Finally added Ctrl+Left/Right jumping between cells, and a couple other small things I’ve been wanting to do.