Here's a set of files from a simple Bass loop:
1) MP3 recording
2) MIDI recording (from Orba USB to a DAW)
3) Song file
4) Bass LoopData from the song file
5) Full loop info from the console with header
6) MIDI notes only from the loop info
Looking at (6), the last note in the data is the first note in the tune. Maybe that's just the timing of the playing. There's been no attempt to quantise it. It would be interesting to try and change one of the notes.
I found this a bit of a fiddle, but hopefully it's right.
When I was looking at it yesterday, I think it was showing a log like this while playing at one point.
I wasn't able to get into that mode just now, but comparing it with the "loop info" file from this other loop might be helpful while trying to figure out the LoopData string.
LoopData might contain some of the header info before we get to the MIDI data. I tried decoding the first 19 characters of the LoopData and comparing the values. A couple of the numbers might correlate, eg:
Index 2 and Index 10 = 74 = ccB
Index 16 = 75 = ccC
Trial and error I guess; not sure what ccA/ccB/ccC even are yet...
I just tried recording a few different bass loops and looking at LoopData.
For the first one,I started with "All Out", let it count four metronome clicks in, played the lowest note, then pressed the central button to stop recording on the third click after that. I then repeated with the next two notes up.
Comparing the strings:
F3wHdxQAAFEVAAAAACAQAAA5dSRoAA==
FxcAaxQAAFUVAAAAACAQAAA7eUpVABRIADA=
F2MHYhQAAGYVAAAAACAQAAA9cTlyAA==
I've found that other similar loops have the same string from characters 12-23:
VAAAAACAQAAA
This is followed by 5, 7 and 9 in the three strings. These decode to 57, 59, 61 at index 17, which are the MIDI note numbers the Orba sends. So, it looks like the MIDI data sequence starts there.
I've attached a CSV with some of this info. The set of values under the eventData are taken from other parameters in song file's LoopData entry.
...so far so good. I've been able to record a tune on Bass, then fiddle the Song file to change the first note. It'll get a bit more complicated after that beause there might be an arbitrary number of CC messages until the next one.
>"I suspect its the exact same data from the MemIdx above"
...yep, I guess eventData is basically a list of MIDI event codes followed by MIDI event data. Time to hit the loop logs again.
...this is going to be a lot easier if I start again with a set of songs for one gesture at a time, starting with tap only...
...that data file I uploaded above was the wrong one, ignore that...just some rough notes. Here's the correct one...
I'm finding it more difficult than I thought to repeat this experiment with "tap only" presets.
1) I couldn't see how to create a tap-only copy of a song file because they don't contain Modifier lists.
2) I couldn't seem to create a tap-only Bass preset by only keeping the first Modifier/Seeker pair.
3) Something seemed to go wrong with the song-saving system when I started trying to work with tap-only Lead presets, and the eventData looked different.
Next step will be to try starting over with a full, original Lead preset and try and pick out the header + starting note again.
It makes sense that there is header data which seems to correspond with this:
loopBarEndTolerance: 120
beatLengthTicks: 480
notesPerBar: 4
quantMode: 1
quantStartSnapTicks: 120
quantBarEndSnapTicks: 240
allowRecordingSilenceStart: 1
allowRecordingSilenceEnd: 0
thinnerMode: 1
cc_error_limit: 1000
pbend_error_limit: 25000
ccA: 1
ccB: 74
ccC: 75
thickenerMode: 1
thickenerEmitPrd: 20
thickenerMaxDt: 5000
noteStartWindow: 240
You said that indexes 0-17 appear to be the header and there are 18 values here. Base64 gets converted to an array of 8-bit numbers (0-255) but some of these values require less space (booleans such as thickenerMode 0/1 only requires 1 bit) and some are larger requiring two bytes. I'm not sure how these are packed but I'm really hoping they match the headers above. I've been quite busy that last 3-4 days and haven't had much of a chance to dig in. Fortunately, I rebuilt my PC and have my Windows machine back up (with better hacking tools than my Mac).
Just some notes on workflow...
I've now been abloe to record a set of songs with tap-only data. The method is:
1) Load 1981 and quit the app
2) Create a copy of the 1981 Lead preset with tap only (first Seeker/Modifier only) and Major scale
3) Record a sequence
4) Run the app and quit it again, saving the song
5) Make a copy of the new song file version the App has created and give it a suitable name
6) Clear the sequence and repeat from (3)
Usually the App makes successive copies a song as you record new sequences, but after feeding it a tap-only Lead preset I couldn't get it to go beyond the first one.
*****************************************
I've found that the console event list posted above shows live events while recording; I don't think you can get that view during playback.
The Looper info logs (1-4 in consoel) are a bit strange. If you record with sequences in the console, they get populated, but if you load a song containing event data, they don't. However, if you record another note on the end, then that shows up, and the previous data shows up too.
The Looper info log for this song that you're extending displays in a "live" readout kind of way; if you keep tapping the relevant number for that loop (Bass/Lead/Chord/Drums) whie it's playing, it shows all the info up to that point.
So to recap, to get the console Looper info from a song you've loaded from the App, you need to:
1) Quit the App
2) Turn the Orba off and on again
3) Connect via eg Putty
4) Put the Orba in Record mode
5) Add another note to the sequence you've recorded
6) Tap the relevant loop button (1-4) just as the loop ends
Here are some files from a duration/timing test. There's an MP3 of the loop, and a CSV giving data from:
1) MidiOx MIDI monitor (from Orba's USB/MIDI)
2) loopData
3) Decoded eventData
4) Console data (with extra final note in order to generate the report)
The loop is all on one note, and consists of:
1) Two notes with duration of 1 click, separation of 1 click
2) Two notes with duration of 2 clicks, separation of 2 clicks
3) Two notes with duration of 3 clicks, separation of 1 click
Looking at eventData, there's an unknown negative value after release velocity. This is followed by a value that's 1 for the first two notes, 3 for the second two notes, and 5 for the last two, so it looks like that's related to duration.
Just to clarify the timing of the performance:
click - on
click - off
click - on
click - off
click - on
click
click - off
click
click - on
click
click - off
click
click - on
click
click
click - off
click - on
click
click
click - off
Every note value (62=D4) has a value of 16 three places before it, with the first 16 being the start of the data. Perhaps this represents the "Play a note" event or the MIDI channel number. It looks like eventData bundles note-on and note-off into a single entry which includes timing, note, duration, attack velocity and release velocity...?
I forgot to include the LoopData in the "Lead Test" .csv posted previously (which looked at different simple patterns of repeated notes). Here's an updated version with this added.
>"The Orba data has a 0 which I think may represent the Note On event, followed by MIDI note"
I've also realsed that these "0" values are what I called "Duration" in the next test I posted, which looked a durations of 1, 2 and 3 clicks. The value in those were 1, 3 and 5 respectively. In the "Lead test" the notes were very short taps resulting in a 0 value.
I've relabelled them as "Duration-related"; not sure exactly what they represent yet.
There are different ways of measuring time. You can say, "Start at X, and end at Y". Or you could say, "Start at X, for duration Z".
I was starting to wonder whether the timings in eventData were absolute or relative. It looks as though each note event is a block of 8 values from the beginning of the list, with no header.
1) 16 (Tap note command?)
2) +ve and -ve (?)
3) Low +ve (?)
4) Note value
5) Attack velocity
6) Release velocity
7) -ve (?)
8) Low +ve
I was looking at the "Memidex" list in console, which also shows blocks of 8...
MemIdx = 0 - MIDI Note at tick 12, channel 1, note 62, duration 496, von 99, voff 85
MemIdx = 8 - MIDI Note at tick 944, channel 1, note 62, duration 464, von 127, voff 87
MemIdx = 16 - MIDI Note at tick 1908, channel 1, note 62, duration 960, von 121, voff 87
MemIdx = 24 - MIDI Note at tick 3845, channel 1, note 62, duration 996, von 117, voff 80
...and remembered the tip from @Subskybox.
I suspect [eventData] is exact same data from the MemIdx
So...it does look like it. The next question is working out what order it's in. Need to test durations that get longer and then shorter again...
Andrea Mannocci
This thread is intended to gather the feedback of Orba tinkerers.
29 people like this idea