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.
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.
Cool new sounds for Orba 1. I'm going to try to port some to Orba 2.
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.
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.
...actually, the console quantization setting seems to stick through song changes and power cycles. Once it's on, it stays on. I haven't been able to change the value of it in the XML yet. I'm not sure how useful it is without being able to change the parameters, but it's worth knowing about. I'll be interested to see how it's implemented in Orba 2.
No idea...but now that they finally seem to be in stock at Gear4Music, I've just re-ordered one...
I can't find the loop info parameters anywhere except in 0x8000000.bin, where they look like this:
Looper Configuration:
loopBarEndTolerance: %u
beatLengthTicks: %u
notesPerBar: %u
quantMode: %u
quantStartSnapTicks: %u
quantBarEndSnapTicks: %u
allowRecordingSilenceStart: %u
allowRecordingSilenceEnd: %u
thinnerMode: %u
cc_error_limit: %lu
pbend_error_limit: %lu
ccA: %u
ccB: %u
ccC: %u
thickenerMode: %u
thickenerEmitPrd: %u
thickenerMaxDt: %u
noteStartWindow: %u
The Orba.exe app starts with:
quantStartSnapTiMZ
...as the first data, and that's about it.
...I've tried adding stuff like:
<SynthPatch mode="Lead" quantizationMode="1" loopBarEndTolerance="2" quantStartSnapTicks="2"
quantizationStartSnapTicks="2" ccA="2" thinnerMode="2" allowRecordingSilenceEnd="2"
...to the presets, though that XML doesn't actually appear anywhere, but it doesn't seem to have any effect. I suspect that running the App may turn quantisation off again, though I think it survives power-off.
I don't think that would work since those appear to be channel level settings. Do you have the eventData that matches the log (Channel 1)?
...I don't think the eventData has a header...? Here's one version of the seven-note "DPC" sequence (song attached) and the data is seven blocks of eight values, each starting with 16; ie just the seven note blocks. The previous "Duration test" (MP3 and CSV) was the same, just the six note blocks in the eventData.
...there's the rest of LoopData though, eg for the attached song:
writeIndex="56" recordStartTime="0" recordStopTime="11882" lastEventTime="4809" nBars="7" eventDataCrc="1ff6d4c4"
I notice that song files have quatizationMode and volume
<Mode name="Bass" quantizationMode="0" volume="200">
Have you changed those while the hardware Quantization is on?
Unfortunately I can contribute nothing but admiration. I read along in awe, without understanding much of it. :-)
If you Google 'ESP32 web server files'...might it be set up something like that...? I'm not sure where you found that reference but it looks like a URL. (Obvs this is more your field of expertise than mine.)
Andrea Mannocci
This thread is intended to gather the feedback of Orba tinkerers.
28 people like this idea