Artiphon

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.

The ModifierEntry lists seem to be unnecessary. I have been trying to create a template for making Orba 2 presets. I have resorted to using a few seeker entry sets that I know are "safe" and choosing (by trial and error) which ones work as I hope with the synthPatch I'm working on. Altering parameters as little as I can. For the moment this seems the best way (for me, at least) to go. The problem with that is that it's hard to understand what each ones does and how it will work with different patches - so it's far from ideal.

But the knowledge you guys are bringing help in understanding it all. I will try and add the little crumbs I find to it as I can.

You may be right; trying to remember but I think a lot of the Modifier stuff in the Orba 1 XML maybe didn't do a lot. As far as I remember, the Seeker lists represented a bunch of different stuff, starting with the basic event of playing a note, and proceeding through various types of expression/movement such as tilt etc. IIRC the first Modifier entry in chord presets held the data that encoded the chords, via a system that @Subskybox figured out. 

Last time I was looking at the Orba 2, back in November, @Subskybox had pointed out that you couldn't play two different chords at once in the same way that you could play two different lead notes at once and I was investigating that. Then it all went pear-shaped.

**************************************************************************************

**************************************************************************************

Orba 1 was always recoverable, so you could try all kinds of random experiments secure in the knowledge that a reset would sort it out. With Orba 2, unfortunately, that ain't so, unless we can find a new way to access the data partition.

If you connect to a desktop computer via USB and open the Orba 2 app, it likely will restore your Orba 2.

@Artiphon @BJG145

Orba 2 should always be recoverable as mentioned above.. However, it is not as BJG145 points out (he even has a video of the boot loop the device is stuck in). I would encourage Artiphon to examine the device that BJG145 is/has sending/sent back. Perhaps changes to future firmware could be made to prevent this from happening. 

I think I have come to some understanding of the seekers and the mod entries in the synth patch.

All of this is pure guessing, speculation and hopefully enough logic to make sense. So none of this should be considered to the truly accurate.

The mod entries in the synthPatch relate to the three allowed "effects" for each gesture - which is done by altering parameters in the patch on the go. However, there are 4 main groups of mod entries. The fourth group relates to the global chorus and reverb effects and so don't count as part of the three allowed. Whether this group comes first ie: modSource1, or last ie: modSource4, I'm not certain.( I suspect the existence of a 1_2 etc. or 4_2, whichever, is sometimes redundant.)

The format of these entries is modSource1_1. The first number, I have already covered, the second possibly relates to the Oscillator (1 or 2) and 3 relates to VCA or LFO. Someone who understands synth programming may be able to clarify that last idea. The destination parameters I think relate to the various options listed in the dropdown menu in the Gesture Mapping section of the Orbasynth app. Weight hopefully is obvious - how much it affects the chosen parameter.

Seekers relate simply to the collection of data from sensors and translating the data to the programs functions.

My theory is that inMax and inMin entries relate to data that is coming in (obviously). Whether they define the limits it accepts, or the limits of what it will act on, I don't know. I can see some use of the latter.

outMin and outMax is what the incoming values are translated to for the program to use. Again these limits might define what values can be used by the program or if values are outside that limit they can be adjusted or ignored.

The "seekerType" seems a simple intruction - either seek for Note (the keyboard presses) or Controller (the motion sensors) data. The "controller" parameter remains unclear to me. The mix of numbers and "Pitch Bend" in text in the parameters is understandable perhaps, but Aftertouch in there mystifies me a bit.

In "eventSource", Default Note Source, is presumably the keys - what the "Secondary Note Source" is I don't know - perhaps it's a bump (and/or shake?) which have to be handled differently. (This seems a bit confusing because it sort of duplicates "seekerType". Perhaps seekerType calls an action to collect the data, while eventSource defines how it is used when received.

"triggerSource" and "triggerRule" set what will get the effect going - ie: it could be as soon as a key is pressed, or only when gesture data is incoming, or a gesture indicates that the effect should start.

The "metricSensor" is simply whether data is from the keys or the motion sensor. Perhaps it's just a flag for the program.

"metricSelection" is what set of data is to be exported and relates it to midi usage. However this is for both the Orba itself as well as midi signals to other devices. Since "Shake" doesn't have a midi equivalent this would explain the mismatch in the parameters format. MPE X and Y are like graph axis on the key surface, Z is tilt. (Somehow this doesn't seem quite as certain now than it seemed when I first thought it up.)

"maxRate" I think is about how frequently the sensors are polled. Whether this is a timing such as 20 milliseconds apart or 20 times per second I don't know. I think, however, it may be important as it may force the device to try and process more than it handle, causing glitches in the sound output - hence the need for different values for some situations.

The reason you can't get an effect without both the mod and seeker settings is because if you don't use the data incoming you ain't gonna get the required output.

As ever ,I hope this helps and apologise if it's already known.

I should have added that the other synthPatch settings seem to correlate to the various settings you can make in OrbaSynth but since they are labelled and ordered  differently it can be a bit hard to work out what exactly matches what - I've been trying and I'm not certain about some.

Seems I was wrong about the global reverb and chorus being a fourth group in the mod section. These are dealt with in other synthPatch settings. At the moment my best guess is that the fourth group is currently redundant - perhaps it's just there for possible future use?

I have noticed some issues relating to pitch (or tuning) on the Orba (both 1 and 2).

I have been trying to make a sample based lead preset (a process more involved than I had anticipated).

I used a couple of different presets as examples for file names etc. and I noticed that the pitches in the parameters of some were not consistent with regard to octaves - this is understandable as some instruments are notated in a different octave to the one they actually or perceived as in. The guitar is one example of this. And, of course, transposing instruments like most (all?) brass instruments are also written in different pitches than they sound - but I guess those familiar with that compensate.

Some presets have been made to play in a particular key which may also add complications.

But I also realised on one patch in particular that they seemed not to be in concert pitch - the tell tale indication was that there were no notes at A440 (concert pitch standard), A880 (the octave above) or A220.

I recall there has been come concern that bass presets were sometimes out of tune with chords and/or leads. I think the problem here may be that presets made in sets may not be compatible with presets from other sets if they were made in different pitches. That might happen for a variety of reasons, but what it means is that mixing presets from different sets may clash in regard to pitch.

I'm not familiar about how the Orbas handle pitch with samples so perhaps the problems come from how the Orba handles them, but it might be down to how the samples are made and described in a preset.

>>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.

@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 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.

@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'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.   

@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!)