Start a new topic

Orba 2 Hacking Knowledge Base

image

This forum is intended to share Orba 2 hacking tips amongst the Orba 2 community. NOTE: Please post facts that are well understood & useful. If you have theories to discuss, please start another forum and link to it here.


2 people like this idea

I can only describe my thinking - which I imagine may well be too simplistic.


I am thinking, in terms of a graph with the x axis being either the rate of change of the application of the effect or the total amount of effect at each point in time (which would be constrained by parameters in the patch probably) - because I see the Y axis as time (although this might be better thought of as the passage through a gesture).


I assume only a simple curve - a C shape and perhaps S - is used. Something more complex might be considered desirable, but would you really need it? (I also thought why make it more complicated than needed when the computing power is limited?)


Going back to my vector art thinking only 4 coordinates would be required -  a start and end position and the co-ordinates of the two "hooks" that define the actual curve. This would require 8 numbers to be passed to whatever routine actual does the calculations. It seems to me that the start and end point in time (Y) could be derived from the parameters in the patch, perhaps the weight (X) as well. But they may be included for convenience. (Quite why they should be obfuscated in a base64 string rather than just hex I don't know.) 

Sticking with that idea there could be four hooks, as I have sometimes seen, and that would tie in with your breakdown of the numbers as in your previous post.


The straight line you found seems to fit with what I would expect - an even addition to the effect over the passage of the gesture. Perhaps the other strings simply define a basic set of curves which could be used, keeping the whole thing simple. To me that seems a sensible approach - giving options that can be simply applied by preset designers. If they are lazy a designer might simply try a straight line first and not bother to try others to see if they work better - which would have been a good idea on the Tilt Lead preset in my opinion. This would be good for us too, because we could stick to known safe strings to use and with some degree of understanding what they will do.


And I agree you may have cracked it!




I think I've got it! It appears to be using the Float (IEEE754 Single precision 32-bit) standard and is recorded in reverse (many programs do this to simplify bit-shifting). I converted the curve:


[0,0,0,0],[0,0,0,0],

[113,244,40,70],[113,244,40,70],

[113,244,168,70],[113,244,168,70],

[0,254,255,70],[0,254,255,70]


to


0.0 , 0.0

1.08131103515625E4 , 1.08131103515625E4 

2.1626220703125E4 , 2.1626220703125E4 

3.2767E4, 3.2767E4 (Note this value is the max value for a 16-bit signed int)


..which is completely linear! This can't be a coincidence. I'll need to convert the other curves this week to see what all the curves look like. The first one is here:


image



1 person likes this

Based on the above, my assumption is that there are several Bezier curves defined. I would guess that one Bezier is defined like this:


[0,0,0,0],[0,0,0,0],

[113,244,40,70],[113,244,40,70],

[113,244,168,70],[113,244,168,70],

[0,254,255,70],[0,254,255,70]


as


[P0x],[P0y],

[P1x],[P1y],

[P2x],[P2y],

[P3x],[P3y]


image

I assume that the first Point is bottom left [0,0,0,0][0,0,0,0] and that the last Point is top right [0,254,255,70],[0,254,255,70].


image


I'm then going to speculate that each of the 4 integers somehow represent a 32 bit number (likely a float). I'm going to research some different ways of storing these numbers and can hopefully find the right schema. I feel like I'm on the right trail.



Here are the 7 BezierCurvesEntries along with the Presets they are used with. Note: pattern 7 published above is unique to the Ambient Chord Preset. I played with this sound to find out what was so special about it. I found this sound has NoteOff velocity which I hadn't noticed from any sound before. I'm not sure how this is achieved or even if the Bezier curve(s) have any impact. 

txt
(476 Bytes)
txt
(4.12 KB)
txt
(475 Bytes)
txt
(4.02 KB)
txt
(475 Bytes)
txt
(3.28 KB)
txt
(2.8 KB)

I'm also looking at BezierCurvesEntry which has 7 unique Base64 strings:

bezierCurvesData="AAAAAAAAAABx9ChGcfQoRnH0qEZx9KhGAP7/RgD+/0YAAAAAAAAAAHH0qEaOj21EUt/6Ru1F4UUA/v9GAP7/RgAAAAAAAAAAZ5gZRsLVo0N7UDhGUt/6RgD+/0YA/v9GAAAAAAAAAABx9ChGcfQoRnH0qEZx9KhGAP7/RgD+/0YAAAAAAAAAAHH0KEZx9ChGcfSoRnH0qEYA/v9GAP7/RgAAAAAAAAAAcfQoRnH0KEZx9KhGcfSoRgD+/0YA/v9GAAAAAAAAAABx9ChGcfQoRnH0qEZx9KhGAP7/RgD+/0YAAAAAAAAAAHH0KEZx9ChGcfSoRnH0qEYA/v9GAP7/Rg=="/>
bezierCurvesData="AAAAAAAAAAAbIdtFuHmURkLVY0atYNBGAP7/RgD+/0YAAAAAAAAAAHH0qEajwHVEUt/6Ru1F4UUA/v9GAP7/RgAAAAAAAAAAZ5gZRtDVo0N7UDhGUt/6RgD+/0YA/v9GAAAAAAAAAAC+J5xGwtWjQ6PA9UbC1SNEAP7/RgD+f0YAAAAAAAAAAHH0KEZx9ChGcfSoRnH0qEYA/v9GAP7/RgAAAAAAAAAAcfQoRnH0KEZx9KhGcfSoRgD+/0YA/v9GAAAAAAAAAABx9ChGcfQoRnH0qEZx9KhGAP7/RgD+/0YAAAAAAAAAAHH0KEZx9ChGcfSoRnH0qEYA/v9GAP7/Rg=="/>
bezierCurvesData="AAAAAAAAAABx9ChGcfQoRnH0qEZx9KhGAP7/RgD+/0YAAAAAAAAAAHH0qEajwHVEUt/6Ru1F4UUA/v9GAP7/RgAAAAAAAAAAZ5gZRtDVo0N7UDhGUt/6RgD+/0YA/v9GAAAAAAAAAAC+J5xGWDKiQ00x80aspBtEAP7/RgD+f0YAAAAAAAAAAHH0KEZx9ChGcfSoRnH0qEYA/v9GAP7/RgAAAAAAAAAAcfQoRnH0KEZx9KhGcfSoRgD+/0YA/v9GAAAAAAAAAABx9ChGcfQoRnH0qEZx9KhGAP7/RgD+/0YAAAAAAAAAAHH0KEZx9ChGcfSoRnH0qEYA/v9GAP7/Rg=="/>
bezierCurvesData="AAAAAAAAAAAbIdtFMDiURifIY0atYNBGAP7/RgD+/0YAAAAAAAAAAHH0qEaNj21EUt/6RutF4UUA/v9GAP7/RgAAAAAAAAAAZ5gZRsLVo0N7UDhGUt/6RgD+/0YA/v9GAAAAAAAAAAC+J5xG0qujQxe69UYNBCNEAP7/RgD+f0YAAAAAAAAAAHH0KEZx9ChGcfSoRnH0qEYA/v9GAP7/RgAAAAAAAAAAcfQoRnH0KEZx9KhGcfSoRgD+/0YA/v9GAAAAAAAAAABx9ChGcfQoRnH0qEZx9KhGAP7/RgD+/0YAAAAAAAAAAHH0KEZx9ChGcfSoRnH0qEYA/v9GAP7/Rg=="/>
bezierCurvesData="AAAAAAAAAABx9ChGcfQoRnH0qEZx9KhGAP7/RgD+/0YAAAAAAAAAAHH0qEaNj21EUt/6RutF4UUA/v9GAP7/RgAAAAAAAAAAZ5gZRsLVo0N7UDhGUt/6RgD+/0YA/v9GAAAAAAAAAAC+J5xGWDKiQxe69Ub/LSNEAP7/RgD+f0YAAAAAAAAAAHH0KEZx9ChGcfSoRnH0qEYA/v9GAP7/RgAAAAAAAAAAcfQoRnH0KEZx9KhGcfSoRgD+/0YA/v9GAAAAAAAAAABx9ChGcfQoRnH0qEZx9KhGAP7/RgD+/0YAAAAAAAAAAHH0KEZx9ChGcfSoRnH0qEYA/v9GAP7/Rg=="/>
bezierCurvesData="AAAAAAAAAAAbIdtFMDiURifIY0atYNBGAP7/RgD+/0YAAAAAAAAAAHH0qEaNj21EUt/6RutF4UUA/v9GAP7/RgAAAAAAAAAAZ5gZRsLVo0N7UDhGUt/6RgD+/0YA/v9GAAAAAAAAAAC+J5xGWDKiQxt/9UaspBtEAP7/RgD+f0YAAAAAAAAAAHH0KEZx9ChGcfSoRnH0qEYA/v9GAP7/RgAAAAAAAAAAcfQoRnH0KEZx9KhGcfSoRgD+/0YA/v9GAAAAAAAAAABx9ChGcfQoRnH0qEZx9KhGAP7/RgD+/0YAAAAAAAAAAHH0KEZx9ChGcfSoRnH0qEYA/v9GAP7/Rg=="/>
bezierCurvesData="AAAAAAAAAABx9ChGcfQoRnH0qEZx9KhGAP7/RgD+/0YAAAAAAAAAAHH0qEaNj21EUt/6RutF4UUA/v9GAP7/RgAAAAAAAAAAZ5gZRsLVo0N7UDhGUt/6RgD+/0YA/v9GAAAAAAAAAABx9ChGcfQoRnH0qEZx9KhGAP7/RgD+/0YAAAAAAAAAAHH0KEZx9ChGcfSoRnH0qEYA/v9GAP7/RgAAAAAAAAAAcfQoRnH0KEZx9KhGcfSoRgD+/0YA/v9GAAAAAAAAAABx9ChGcfQoRnH0qEZx9KhGAP7/RgD+/0YAAAAAAAAAAHH0KEZx9ChGcfSoRnH0qEYA/v9GAP7/Rg=="/>

Each decode to 256 values. Here I split the last one in groups of 8:


0,0,0,0,0,0,0,0,

113,244,40,70,113,244,40,70,

113,244,168,70,113,244,168,70,

0,254,255,70,0,254,255,70,

0,0,0,0,0,0,0,0,

113,244,168,70,141,143,109,68,

82,223,250,70,235,69,225,69,

0,254,255,70,0,254,255,70,

0,0,0,0,0,0,0,0,

103,152,25,70,194,213,163,67,

123,80,56,70,82,223,250,70,

0,254,255,70,0,254,255,70,

0,0,0,0,0,0,0,0,

113,244,40,70,113,244,40,70,

113,244,168,70,113,244,168,70,

0,254,255,70,0,254,255,70,

0,0,0,0,0,0,0,0,

113,244,40,70,113,244,40,70,

113,244,168,70,113,244,168,70,

0,254,255,70,0,254,255,70,

0,0,0,0,0,0,0,0,

113,244,40,70,113,244,40,70,

113,244,168,70,113,244,168,70,

0,254,255,70,0,254,255,70,

0,0,0,0,0,0,0,0,

113,244,40,70,113,244,40,70,

113,244,168,70,113,244,168,70,

0,254,255,70,0,254,255,70,

0,0,0,0,0,0,0,0,

113,244,40,70,113,244,40,70,

113,244,168,70,113,244,168,70,

0,254,255,70,0,254,255,70


There's definitely some patterns here. I'm not really sure what these do yet but I'm going to try to build a list of Preset types/names that use each of the 7 strings to look for patterns.

I found this image online:

image

I'm trying to see if there is a way to split these arrays that might correspond. One way to split them as you suggest is like this:


Drum:

AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEEAQEBAQE=

[1,

 1,1,1,1,1,1,1,1,

 1,1,1,1,1,1,1,1,

 1,1,1,1,1,1,1,1,

 1,1,1,1,1,1,1,1,

 1,1,1,1,1,1,1,1,

 4,1,1,1,1,1]


Lead & Bass:

AQUFBQUFBQUFAQEBAQEBAQEBAQEBAQEBAQYGBgYGBgYGAQEFAQEBAQEEAQEBAQE=

[1,

 5,5,5,5,5,5,5,5,

 1,1,1,1,1,1,1,1,

 1,1,1,1,1,1,1,1,

 6,6,6,6,6,6,6,6,

 1,1,5,1,1,1,1,1,

 4,1,1,1,1,1]


Chord:

AQUFBQUFBQUFAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEFAQEBAQEEAQEBAQE=

[1,

 5,5,5,5,5,5,5,5,

 1,1,1,1,1,1,1,1,

 1,1,1,1,1,1,1,1,

 1,1,1,1,1,1,1,1,

 1,1,5,1,1,1,1,1,

 4,1,1,1,1,1]


I'm not quite sure if this is correct?! One thing is for sure, don't spend any time trying to find patterns in the Base64 string. I went down that rabbit hole last year and any patterns you find are just coincidence. The magic is in the number arrays somewhere..

@Subskybox

As a quick experiment I tried to add the drum data to a lead preset with only Pitch Bend to test a gesture.

First thing - it didn't break the preset!

However it made little, if any, difference. Perhaps for the last twenty degrees or so of a 90 degree tilt, pitch bend stopped changing. I think it continued through all 90 previously.


The drum data strikes me as almost vanilla as they could be, except for the one shared digit near the end. It made sense to me that the first group of data would be unique to drum presets - they are rather different in that the sounds usually have a short duration. (And that the drums should be diffeent.)


It does strike me that there could be something to infer about the differences between chords and the lead and bass but I can't really see why chords should be different.


If the first digit is a flag or header we then have 4 groups of 8 digits (perhaps) and after that a different two groups, where only the third digit is not 1.

(In the 4 groups the digits are all the same in the examples we have - not so in the remainder.)


I think I read somewhere that the last "=" character in base64 is some sort of meaningless filler. I didn't really understand what I read, but perhaps the "AQ" are just the filler first character in each set ot 8?


(I like your highlighting of the differences, by the way - really helpful.)


What all this can mean in regard to bezier curves is beyond me I'm afraid - I could only try and read them in terms of how they would be drawn in a vector art context, and that didn't seem to work to me .


It's a bit sad of me that I'm now fascinated by this puzzle!


1 person likes this

I was surprised at the results of the raw data. The Base64 strings produce an array of 47 values:


Drum:

AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEEAQEBAQE=

[1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,4,1,1,1,1,1]


Lead & Bass:

AQUFBQUFBQUFAQEBAQEBAQEBAQEBAQEBAQYGBgYGBgYGAQEFAQEBAQEEAQEBAQE=

[1,5,5,5,5,5,5,5,5,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,6,6,6,6,6,6,6,6,1,1,5,1,1,1,1,1,4,1,1,1,1,1]


Chord:

AQUFBQUFBQUFAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEFAQEBAQEEAQEBAQE=

[1,5,5,5,5,5,5,5,5,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,5,1,1,1,1,1,4,1,1,1,1,1]


Please share your thoughts if you spot any patterns here.

@DavidBenton Totally agree.


I have a good understanding of Bezier curves (I've done some visual programming with them in the past) and I also understand exactly what you mean -- the linear relationship that I'm looking for... So I'm hoping I'm well suited for the job. I do believe I came to a full stop last time I tried with Orba1 Bezier curves, but I'm willing to try again. If I can decipher how they are recording the points, I could certainly figure out how to get a linear relation between sensor input and selected velocity. I'll share the raw data from those strings soon and maybe if a number of us stare at them, we can figure it out :)


I do already see a pattern in that 'AQ' appears to be some type of delineator.

@Subskybox - I had been thinking about both of these things myself over the last few days. 


I had been wondering whether the Compatibility settings might be cause of the problems I 've been having with another sample based preset I was trying to make. At first I'd had the dreaded white noise -  from 32bit versions of the samples , then hearing only synth or a mix of sample and synth, or nothing at all. I was going to start that one again from scratch. I think I might as well try these other settings to see what happens!


I did have also have a theory about the bezier curves which is as that if their line was straight you could get an even application of the effect throughout the passage of a gesture. Whereas a curved line would produce little increase in effect where the gradient was low and a lot when the gradient was high. This would allow the possibility of the early movement of a gesture to do little and it really kick in on the later movement. For pitch bend this could make it possible to simply play in tune with a certain amount of movement not a problem, and then only changing pitch significantly as wanted. 

(I'd kept quiet about that because I knew I wouldn't have the maths to work out what to do about it!)


1 person likes this

I'm looking at GestureCurveAssignmentsEntry. It contains an attribute called curveAssignmentsData which I believe defines one or more Bezier curves. From observations of all the factory presets, I see that there are only 3 variations used:


Drum:

AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEEAQEBAQE=

Lead & Bass:

AQUFBQUFBQUFAQEBAQEBAQEBAQEBAQEBAQYGBgYGBgYGAQEFAQEBAQEEAQEBAQE=

Chord:

AQUFBQUFBQUFAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEFAQEBAQEEAQEBAQE=


Its important to note that Base64 is as follows:

Base64 is a binary to text encoding scheme that is generally used to transfer content-based messages over the Internet. It works by dividing every three bits of binary data into six bit units. The newly created data is represented in a 64-radix numeral system and as seven-bit ASCII text. Because each bit is divided into two bits, the converted data is 33 percent, or one-third, larger than the original data.


Last year, I built a tool to decode these strings and edit them and copy them back as Base64. I'll use it to have a look to see if I can determine exactly what is defined here.  There are a few different Bezier curve types (i.e. cubic and quadratic). These would often require 8 data points in 2D space but I'm not sure how Artiphon has defined these.


The Drum sounds seem louder or respond to less of a velocity curve so there is less variance in the output volumes. I'll report back if/when I crack their system.   


1 person likes this

@DavidBenton. Yes you can do that. Note: The SynthPatch node has several versions as defined by Compatibility (audioEngineMinor) eg:

<Compatibility audioEngineMajor="1" audioEngineMinor="8" samplePlayback="1"/>

Each version of audioEngineMinor supports different attributes. I'm not sure what version they were on when OrbaSynth came out.


A quick grep of the factory presets shows that Orba2 has presets with versions 4,8,10,12

I know this might seem blindingly obvious but it suddenly occurred to me that you can take a synthPatch section from an artipreset file - put it into a orbapreset file and load that into Orbasynth, play around with it and save that as an orbapreset and insert that synthPatch into an artipreset.

Most (all?) of the Orba2 factory presets are Orba1 versions updated so it may not be awfully useful - but it just hadn't come to mind before.


1 person likes this

@Ignis32 - Thanks for the reply, I'll have a look for that thread (I may well have already seen it). I have encountered the 48/44khz issue in the past and I'm well aware of it. It isn't part of the issue I was considering (though it may be the problem in some cases).


I haven't noticed the pitch parameter you mentioned - I will look at that - thanks.


I thought some of the earlier comments about problems were referring to an out of tuneness that was too slight to be the Khz issue. I agree about the possibility of original pitch being a possible cause - I suspect I may find that with the preset I'm trying (and failing so far!) to create at the moment, but at this point I'll be happy if I just get something that will load. Perhaps when I've succeeded with that I might have clearer thoughts on it.

I suppose the point is really that if Artiphon want to have people make songs with the presets they offer they should ensure they conform to a standard regarding pitch to make that work properly. What we choose to do ourselves is another matter.

>>I'm not familiar about how the Orbas handle pitch with samples 

There is a long post in this thread that describes our knowledge on that.


it this the one with phrase "finally written explanation of some internals of the .artipreset"


>>one patch in particular that they seemed not to be in concert pitch 

If you are referring to pitch values in xml being not in line with 440hz, then please notice the following.


 Orba2 uses 48khz samples. If your samples are not 48, it will affect the pitch on playback.

Therefore, if samples are 44khz (I've seen these in factory presets) it is compensated  in "pitch="  


 And for sure, if original pitch was out of tune slightly, it might be compensated via pitch= param as well.


>> concern that bass presets were sometimes out of tune with chords and/or leads


It could be me telling something like that, but I was complaning about scales. Also, there was a bug in orba2, that seems to be fixed in latest orba app. I am not sure how deep the bug was was, but from what I observed - scale picker in orba app was broken, Orba loaded correct  scale initially, but when you were trying to choose scale from app - it was switching to minor instead of major and vice versa.  It might be that my impression about scale incompatibility  between instruments was caused by that bug.


Login or Signup to post a comment