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.

@DavidBenton: For the Clarinet, I used Audacity to find the loop points. The start and end points are the Sample#, not Time (as you figured out). You can set Audacity to show the selection range in samples rather than time:

What you need to do is just guess roughly the area you want to loop and then press 'Z'. This will move the edges of your selection to the nearest 0 crossings.

Next, set Loop to Selection and then play the loop to make sure it sounds clean. You will likely have to repeat this process 4-5 times until you find a clean looping point. Once you do, immediately type these numbers into your .artipreset file for the given sample. It's tedious but it worked for me.

In a drum preset kitPatch each entry has "note="44" midiNote="39"" - whether the Orba pays any attention to it I don't know, I presume midi output does.  I have noticed the same midiNote is sometimes in more than one entry.

In an artisong part of the lead setting, for example we have "    <PresetRef name="Madaharp" fileName="Madaharp_8aee6a9869530ed2cc60c5ac045c368f.artipreset"

               fileHash="12550"/>"

The fileHash is the 10 base value of the crc number the orba gives it when it is stored on the Orba - that is not easily available to non hacker types.

There is also this "    <LoopData writeIndex="0" recordStartTime="0" recordStopTime="0" lastEventTime="0" nBars="0"

              eventDataCrc="FFFFFFFF"/>"

In this case the eventDataCrc for all entries is "FFFFFFFF",  although the song is empty of events - don't know whether it's used or required in any way. (Perhaps it means keep on playing until the user eventually stops the play/recording with A + key5?)

But at this point in time I've not studied it enough.

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:

Just for your amusement - an example of the weird sounds the Orba can make when you start experimenting.

(Don't listen if you are of a nervous disposition!)

@Ignis32 - yes, I had thought loop points might have been time based - but I have learnt better since!

I don't want to use existing sound fonts - I was planning on making my own, and I'm not too keen on the idea of having to figure out about them first.

What you say partly supports what I might have first tried which would be to calculate a start point and try an end point by adding a number that would be a multiple of 16 - that should tie in with what you have suggested. So thanks for that.

I have tried looking at Juce documentation for hints about things like this - but it hasn't really helped much! (And I barely understand most of it.)

It will take a bit of time for me to get round to making the samples so I'll see what else I can find in the meantime.

I almost fell into the trap that bricked your Orba, if I recall correctly. I was trying to make a lead preset from a chord preset - I found the eventSource="Modifier 0 0" caused the Orba to crash and reboot. Luckily it didn't do more than that. I deleted the preset, and edited out that entry before restoring it and all was well.

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.

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

Ah, I've just tried that last attempt I mentioned above. The result works (with lots of pairs of the same notes in the chordLists - it's not quite what I'd hoped but it works (hurray!) and sounds rather nice, but in a different way intended. (There were some compromises to avoid failure.)

My first attempt though sounded very different in the minor. I tried changing the audioEngineMinor parameter in the compatibility section in SynthPatch to match the major sound parameter and hey presto it worked - making them sound the same in tone. (I had not previously expected these parameters to do something like that.)

I will wait a bit and test this out a bit more - just to see if it behaves itself. If it stays good I will post it on the appropriate thread.

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.

I didn't expect it to work, but I couldn't resist trying, and it did work. 

I have been trying to get a two octave range with chromatics as well without using the A/Oct switch. My previous best was by using the harmonics in the preset - but it wasn't convincing. Suddenly I had an idea that I thought might work. Changing octave (or a semitone) is easy using pitch bend (I prefer doing that on the key pads rather by tilt, but both will work ), but I had to find a better way of adding the other half of the puzzle - the solution came by adding duplicate entries of sample files but with different frequencies declared, fooling the Orba  to play them at the frequency I wanted rather than the Orba thought it was doing.

I can now play chromatics effected by the velocity thresholds on the keys, and changing octave for each note depending on the position on the key.

Frankly, it's not ideal in terms of usability - but it does work. More of a proof of concept than good viable plan -  it might be better if I'd used tilt for the octave changes but I have found with that you need to be very nifty indeed to avoid unwanted pitches playing when changing over.

I just thought I would note it here in case anyone is interested!

@subskybox - I took the liberty of making a version of your PanDrum (v9) with adjusted pitches and velocity thresholds which will play better  in tune with other presets I think. It seems to sound a bit different and perhaps less character, but has some nice qualities. I won't share it unless you are OK with that -  it's still much more your work than mine.

Thanks for this. When I first received my Orba 2, I had a look through the Orba 2 App binary and found the following:

  <TuningList category="percussion" keySelection="false">
    <TuningEntry name="All Kicks" />
    <TuningEntry name="Drum Kit" />
    <TuningEntry name="Electro Kit" />
  </TuningList>
  <TuningList category="tonal" keySelection="true">
      <TuningEntry name="Major"            type="tonal" intervals="P1, M2, M3, P4, P5, M6, M7, P8" />
      <TuningEntry name="Natural Minor"    type="tonal" intervals="P1, M2, m3, P4, P5, m6, m7, P8" />
      <TuningEntry name="Harmonic Minor"   type="tonal" intervals="P1, M2, m3, P4, P5, m6, M7, P8" />
      <TuningEntry name="Melodic Minor"    type="tonal" intervals="P1, M2, m3, P4, P5, M6, M7, P8" />
      <TuningEntry name="Major Pentatonic" type="tonal" intervals="P1, M2, M3, P5, M6, P8, M9, M10" />
      <TuningEntry name="Minor Pentatonic" type="tonal" intervals="P1, m3, P4, P5, m7, P8, m10, P11" />
      <!--
      <TuningEntry name="Dorian"     type="tonal" intervals="P1, M2, m3, P4, P5, M6, m7, P8" />
      <TuningEntry name="Phrygian"   type="tonal" intervals="P1, m2, m3, P4, P5, m6, m7, P8" />
      <TuningEntry name="Lydian"     type="tonal" intervals="P1, M2, M3, A4, P5, M6, M7, P8" />
      <TuningEntry name="Mixolydian" type="tonal" intervals="P1, M2, M3, P4, P5, M6, m7, P8" />
      <TuningEntry name="Locrian"    type="tonal" intervals="P1, m2, m3, P4, d5, m6, m7, P8" />
       -->
  </TuningList>

 I thought at one point I had succeeded in Harmonic Minor and Melodic Minor but I haven't been able to re-create this. I had tried setting tunings from the voices and also from the songs to see how to get these to take effect. I believe it had something to do with being in Chord mode but had not invested much time to figure this out. I found it interesting that there are other modes in there but they are commented out. This is likely because it really messes up Chord mode if you leave the current tunings.

Hi all. I'm new to Orba 2 and am trying to add custom presets in different musical modes (Phrygian in this case). I took a preset from this folder:


C:\Users\Public\Documents\Artiphon\Common\Presets\Lead

Modified it, and saved it to this folder:


C:\Users\[user]\Documents\Artiphon\Common\Presets\Lead

However, no matter what I try, I cannot see the new preset in the app. Is this not a functionality that is currently available?

Thanks!


Looking at the factory_content_Songs folder I notice that some (but not all) of the songs in a minor key have intervals parameters showing a minor scale but the tuning parameters  (midi numbers) are for a major scale.

The Wind and Sea song is one example of this. Whether that's significant or not I haven't investigated.

@Andy,

Subskybox will know more about his than I, but the first thing is that drum presets are quite different to the other types. You need at least eight samples for a drum preset (one for each key) and they are handled differently to pitched voices. The inbuilt sampling function is not really suitable for that. 

I suppose Artiphon could create a method for handling it but I don't think that fits in with their view of what the Orba should be.

You could use externally created samples and use Subskybox's method of creating a preset using an existing drum artipreset file as a template. However, the drum presets have different parameters and seem to me to be rather more complicated. (I have looked - but not dared to try anything myself!) Such a preset might also present problems with midi compatibility unless it is made carefully with that in mind.

@Subskybox - thanks about the "s" command thing.  I'm not knowledgeable to try using it myself but good to know all the same!

A while ago I took a look back at the old posts here and was impressed by the thoughts and ideas that were floating around then (and how wrong much of my own were! I know a lot more now).

Before Artiphon messed up the chords presets (especially for the Orba 2, it makes a bit more sense for the Chorda, but still a shame I think) I was thinking about the idea of using pitch bend on the Y axis of the pads and trying to get three notes on each pad, the "true" note and a semitone up and down. It didn't really work with the seekers, not playable realistically.

A new thought came to my head which is that perhaps the gesture bezier curves might provide an answer by creating a curve that will pitch bend the note at the top and bottom of the Y axis but flatten out to do little or none in the middle area. It would perhaps be too fiddly to use on the Orba but could work well for the Chorda simply because the pads are physically bigger and the middle of the pad is effectively marked by the lights in the center of the pad. Tricky to work out how to actually do it though! (Previously I was only interested in the curves for getting a more natural sounding note bending, and recently trying to emulate Steve Winwood's synth lead sound.)