Now I'm really excited. Chrome also has a Serial API. I predict we will be able to change values from the Editor in the future.. :)
Good news I re-read your DFU instructions and the Orba App found it in DFU mode.. I then re-flashed firmware, opened a serial connection and set quantize on. I played back many of the songs I'd previously recorded (some of them quite sloppy) and the all sound pretty decent! definitely tighter. Now you've got me hooked on exploring a bit more. I'd like to see if we can read/update some values in there. I can't seem to get it to do the ascii animation thing. I suspect you need a good terminal for that. I need to go back and re-read your posts on this now :)
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...
So, is there anything to do with v1? I was pissed with v2 annoucement and nothing else than a 10% discount for v1 owners interested in v2. I mean I bought an Orba after waiting quite a while (months) because Quantization was discussed many times and they said it was high on the priority list. Was confident they would deliver. Instead, with too many feedback requesting that feature, they decided to secretly work on a v2 to offer that feature.
Let's face it, at this point in time they will prolly never add that feature to v1, they want to sell v2 instead. So how is this hack working, is it performing well enough to bother? My Orba is collecting dust for 10 months now and was wondering if I should maybe give it to someone else.
In my experience, quantization with Orba 1 does not work that well. It is working quite well for Orba 2. Quantization is still not that great compared to what we expect from modern software. It actually quantizes during recording, not playback so its not something you can turn on/off to hear the difference.
Cool new sounds for Orba 1. I'm going to try to port some to Orba 2.
Anyone ever figure out how to add new preset files to iPhone? I have lots on my PC but I would like them on my iPhone too
I'm just trying to absorb some of the MIDI programming info.
When experimenting with duration and then timing, I got the idea that one of the values represented a count of an eighth of the bar, ie a quaver, and the other value was a +ve/-ve offset from that.
With duration, this seemed to work, and I was able to get fixed length notes by counting quavers and zeroing offsets.
With timing, the "fine" control got more complicated. At one point the loop lost a note or two and started playing at double speed. I also found that even if notes were playing back accurately on the metronome, there was still an offset. With one loop I also found that the first note got moved to the end again. I'm wondering if maybe this happens if the first "trigger" note that starts the recording is played fractionlly behind the beat.
I was also thinking that there was something different about the timing values for the first note in the list, and possibly the last. The data for these two might represent something different. Perhaps there are tick values at the start and ending but the middle values are relative, or something.
The tempo change was strange; the loop was still counting the same length round the dial but it was mostly squashed into the first half, followed by silence. Perhaps there might be some kind of calculation going on between the timing values for the start and finish to work out what the time signature is.
The next thing I was going to try was playing a loop in time, then moving the offsets for notes in the middle of the loop around slightly to see the result.
Here's the serial log for the above test I called "DPC".
* * * * *
I've found that the "coarse" setting for timing (3rd value in each note block) moves the note and subsequent notes around by a quaver when you increment/decrement it, so note timing is relative rather than measured on a clock that runs for the duration of the loop.
The "fine" setting will take a bit more experimenting; I think it's basically an offset like with duration, but there's a complication around the overall timing of the loop.
What I really need is the serial log that matches the csv. I'm going to attempt to predict the log output.
I've just had a look at the csv file from the latest test.. I don't think MIDI is important here now that I see the data. Does the device emit midi when you play back a song.. Actually I think I already know the answer is yes. I have a guess at what the pattern is now that I see your csv. I just need to go test my theory...
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...?
Andrea Mannocci
This thread is intended to gather the feedback of Orba tinkerers.
29 people like this idea