...the results are in. This next test is called DPC or Duration Pitch Change. The files are simply:
1) MP3
2) MidiOx screen grab
3) eventData
This test has seven ascending notes:
1) 1/2 are one click long
2) 3/4 are two clicks long
3) 5/6 are one click long
2) 7 is short
I was main interested in:
1) Whether the first note of the data is the first note of the sequence, and doesn't get bumped to the end. (Previous "Loop Info" console logs had left me wondering. But it's fine, it's in simple order.)
2) Whether the value I've described as "duration-related" would go up and down again. It does. It goes 1, 1, 3, 3, 1, 1. I'm still not sure exactly what it's for, but this is in line with previous results. It seems to be some kind of indicator of duration rounded to the nearest number of clicks.
I'm currently wondering whether the two values following "release velocity" might represent duration as a kind of "fine/coarse" control. That would leave the last two unknowns ( preceding note value) as "fine/coarse" for start-time.
I think start-time is probably absolute rather than relative, for a couple of reasons; partly because that would fit with the Memidx console info, and partly because when I tried to add a bunch of notes to the sequence in a simple way (by copying and pasting the string data multiple times), they all played at once.
@BJG145 said:
I absolutely agree, although I think the reason they moved away from this is that it complicated the use of Chords. It seems in the early stages that they were planning on offering lots of scales (that were defined from the .orbapreset files), but as we know, chords are defined as a series of offsets from the notes of the selected scale. So, if the user can choose from a whole bunch of scales, the chords would get messed up. The modiferData string lets the user define two sets of chords so I think they made the app limit selection to only two scales. I originally thought that the last bit of the ModifierData string would let you define a third chord set that would be applied if your voice was Pentatonic. I think I tested that but I can't remember anymore. It might be possible to hack the Maj/Min selection box in the app to include more scales. I find it interesting that they commented out some of the modes (e.g. Dorian, Phrygian) but left a number of minor modes active. I tried Melodic Minor in a Preset but it doesn't work. It only responds to Major[Pentatonic]/Minor[Pentatonic]. The good news is that the Editor allows you to apply all these scales AND keep the Chords intact.
On the intervals, there is a standard notation for intervals that I remember from my school days. A = Augmented and d is Diminished. See here.
Re: the "Fine/Coarse" duration control, I haven't fully thought this through, but I'm imagining that there's a "coarse" value that counts whole clicks, and a "fine" value that counts the offset within the final click; or something like that.
The start-time data could work in a similar way; one value that counts the number of clicks from the start, and another that counts the offset within the final click. Just a theory so far.
On Uuids, I think that unique identifiers have been created to make things easier for development and to speed up data transfer. For example, I think uploading an Artiphon Preset voice with Uuids will upload to the Orba faster than one without (Unproven). I think the App sends the Uuid to the Orba and if it already has a copy of the associated data, then it can skip the transfer. If it doesn't have that reference, it has to transfer the whole body of data. I found that in the Editor, if I didn't delete the Uuids from the new Preset that sometimes the chord/scale changes would not apply.
My next plan of attack is to look more at the other Modifiers/Seekers to see what we might be able to do. I've always been interested in Pitchbend so that might be a starting point. I've hooked up an external MIDI keyboard and the Orba to my laptop in the past and was able to play the Orba via the keyboard. It didn't respond to the Pitchbend wheel (at least for the voices I tried it with). I was disappointed.
Recently, I found this video I hadn't seen before:
https://www.youtube.com/watch?v=yoxUlNmhQWw
This goes over the Gestures at the start and I do believe it is in some ways false advertising. The Slide gesture as a 'Singing Bowl' could be possible but not without hacking and Spin to control Pitch is also not possible. Perhaps with some hacking it could be. I've imagined adding Tilt to a voice to control pitch (not sure if even possible). The idea is that you could get many more notes in a scale knowing that tilting the Orba to its side would flatten all the notes a semitone. Later in this video, they show arpeggios. I do believe that maybe these had been planned for in the past and that this is what the <PatternList> and <PatternEntry> nodes were for. I haven't messed around with these.
@BJG145 Congrats on the App edits. It would be great if you could find the default quantization setting and flip it back on. Even if its buggy, it would be cool to try.
Looking at the eventData for the last test, it's interesting that every note value is preceded by a 7, except the first one. That makes me think the theory above isn't quite right.
Sooo I'm guessing that they still have not loaded a file load system to put in my own sounds?
I think I'll have to abandon the search for QuantStartSnap for now; the Orba's storage and memory structure seems quite complicated and I don't really understand it.
Everything I've read about the Orba's ESP32 indicates that it has 4MB of internal Flash, but in trying to find the exact upper limits of it, I've been doing some ridiculous Flash reads, up to nearly 16MB. I don't know what or where this block of storage is; it might be internal Flash, external Flash, or even RAM for all I know. I'd have thought that it would be the logical place to store performance data and maybe other settings, but I haven't been able to capture any changes apart from the "Bluetooth area" I mentioned before.
For instance, a couple of consecutive grabs following some changes inserted a few more of these "LE_LOCAL_KEY" commands into a block of them.
There's also an adjacent block of data I'm suspicious of. At other times though, you think, "Surely something must have changed between these two Flash grabs"...and it hasn't. For instance, I just grabbed 16MB of this Flash area; the most I've been able to get hold of; then added a note, powered off and on to save any changes, grabbed it again...and the two files are identical.
********************************************************************************************************
Anyway, I've given in to temptation and ordered an Orba 2. It's not something I'd have purchased without the discoveries that have been made in this thread, but dissecting Orba 1 has made me more fond of it, and developments like Chord Fiddler have considerably enhanced it. Naturally I'll be interested to see what the changes are, and perhaps they'll shed more light on the Orba 1. I probably won't pullit apart though. ;-)
@ Roger, Excellent work there, I knew someone would beat me to it, but then I don't know how to code a GUI.
The Cover images are "Base64" encoded graphics files. Basically an ASCII encoded binary of an image, something I recognised from my days as a Production Engineer back in the '90s, which I had to do sending files over a modem and in the early days of to the WWW when you couldn't send binary files through some of the servers.
So to get the images to work,
Start by extracting the image from the XML file, that is the bit between :-
tagList="#basic" coverImage="
and
"coverImageHash
-: i.e. everything between the two quote marks (") and save as a plain text file.
Fire up an online converter, I used the one here
Use "Import from file" and you should see the Orba image created, if you did it right ;-)
Save the image and read its properties. The important bit is that it is 120x120.
Create your own image, in what ever package you prefer, and save it as a 120x120 PNG file.
Yet another online converter, I used the one here
Create the Base64 text file and insert it into the gap between the two quote marks (") in the XML file.
Sorry if this is a bit wordy, but better too much info than not enough.
Automate that into your editor, and we'll have something to wave at Artiphon as to what we have been waiting for.
Experiments:
1) Changing those 7s to 20s made a mess of the sequence with several notes playing at once
2) Changing the "coarse durations" to 4 made all the note last about 3 clicks
3) Changing the last two values of every block of 8 ("fine/coarse") to 0,4 made every note exactly two clicks
MP3 attached showing before/after this "manual duration quantise". (Ignore the bass note; pressed that by accident.)
The "coarse" value for duration probably rounds to the nearest number of quavers and the "fine" value is an offset to lengthen or shorten it, or something like that.
So for each block of eight values that makes up a note, we have:
1) Play note command. (Probably. Can confirm when we get on to the CCs.)
2) Timing 1...?3) Timing 2...?
4) Note
5) Attack
6) Release
7) Duration - coarse
8) Duration - fine
That just leaves timing...
...sounds great! Perhaps you could select a value (A, B, C# etc) for each chord note from a drop-down...? Or a graphical system based on the keyboard could be handy too if that's possible.
How many notes are there to a chord, or does it vary...? I haven't had a chance to look at the Chord Fiddler yet but but it sounds like you're making great progress. Look forward to experimenting with it over the next couple of days. I'm also wondering what the other characters in that string do, and whether the Chord Fiddler lets you mess with values outside the chord-note string you've identified...
@ Roger - Not sure if this means anything.
I loaded a preset in the editor and saved it without editing anything. After that the picture didn't show in the Orba app; it was replaced by a generic Orba pic. In the editor it showed the original pic. After a compare in a texteditor I noticed a small difference.
In the original file there is a line ending and some whitespace before 'CoverImageHash'. Maybe that keeps the Orba app from displaying the right pic.
By the way, if you save a number with the old Windows app, you can choose a new pic. After that, the file contains the pic data with uuid / coverimagehash. That data can be transferred via copy / paste to other files, such as a preset. Not very practical, but it is possible.
(...or maybe the chord-fiddling system is relative rather than absolute...? In which case you could just select a +/- offset for each chord note...?)
Andrea Mannocci
This thread is intended to gather the feedback of Orba tinkerers.
27 people like this idea