Some statistics for SampleDrumSound elements across all drum presets:
[index]
known values from 0 to 15, avg value: 6.525333333333333
[drumMode]
known values from 0 to 1, avg value: 0.008
[ampVelocity]
known values from 87 to 252, avg value: 200.328
[snapVelocity]
known values from 0 to 255, avg value: 14.661333333333333
[snapLevel]
known values from 0 to 179, avg value: 8.576
[snapColor]
known values from 0 to 4, avg value: 0.33066666666666666
[bendVelocity]
known values from 0 to 255, avg value: 12.773333333333333
[bendDepth]
known values from 0 to 255, avg value: 8.130666666666666
[bendTime]
known values from 0 to 244, avg value: 7.253333333333333
[gainRampStart]
known values from 0 to 0, avg value: 0.0
[gainRampEnd]
known values from 0 to 0, avg value: 0.0
[gainRampTime]
known values from 0 to 0, avg value: 0.0
[clipRampStart]
known values from 0 to 130, avg value: 1.2106666666666666
[clipRampEnd]
known values from 0 to 100, avg value: 1.0506666666666666
[clipRampTime]
known values from 0 to 24, avg value: 15.346666666666666
Not sure it is like very important information, but I've noticed that I am actually trying to see this pattern manually when reviewing all the presets manually, so why note automate this information gathering.
Looks like amount of SampleDrumPatch elements always matches amount of "groups" in sampleMap and velocityThresholds.
Probably SampleDrumPatch note and midiNote do override of some sort for each such group, but I am not still sure how exactly it works.
For example, in Jive drums there are multiple SampleDrumPatch records with the same note "48" somehow, and it does not make any sense to me yet.
Guys, is there any knowledge on how orba actually decides which samples to play when in drum mode?
Looks like I understand how it works for all other types of instruments, but in case of drums end up with wrong samples playing, and it does not make any sense to me.
Seems like KitPatch should do something with that, but sure how it works.
By maximum size I mean maximum known working size, not some sort of limit I'd bumped into.
Trying to track an issue when sample stops transposing in some note range, while pitch is not negative.
(To my understanding negative pitch means static pitch, where it does not transpose)
Sidequest findings, while trying find out where it could go wrong:
1) Orba2 custom preset created by stock method, while generating preset from one single sample - still converts it to several transposed samples, with a octave (12 semitones) distance between them.
Does it mean that there is a limitation on the pitch shifting for more than 12 semitones in orba's internal engine?
2) Maximum current factory sample set folder size is 19.7 Mb (Poolside Chords)
3) Maximum current factory sample size is 1.8 mb ( BPM Horror Drone from BPM Horror drums)
I have 3 a.m here, so I am a little bit short on testing possibilities, but seems to me that I've found a possible workaround for this problem.
This broken configuration as below:
Can be fixed by adding the same sample into group twice, so there will be no decrease in group members amount in the sequence. I mean, all the groups have the same amount of samples.
velocityThresholds="[90],[90],[90],[90],[90],[90],[90],[90],[90],[90],[90],[90],[90],[90],[90],[90],[90],[90],[90],[90],[90],[90],[90],[90]"
sampleMap="[0,0],[1,1],[2,3],[4,4],[5,5],[6,7],[8,9],[10,11],[12,13],[14,14],[15,15],[16,16],[17,17],[18,18],[19,19],[20,21],[22,23],[24,25],[26,27],[28,29],[30,31],[32,33],[34,34],[35,35]
Still working on the SF2->Orba2 convertor.
Made some basic preset xml parser classes lib, loading/modification/exporting works fine more or less, at least input and xml files are quite identical.
sfutils library provides a nice lib for working with sf2, so I managed to read most of the relevant data.
Hope I will convert some creative commons sf2 to orba2 format when convertor would be .. working.. enough.
-----
Meanwhile I've bumped into something that is probably a bug.
Seems like orba2 does not like when amount of samples per group changes, decreases to be exact.
With velocity thresholds as below, every single-sample group (marked with bold) that goes just after two-samples group, plays wrong sample (in my case the sample with index 0, the lowest).
[],[],[90],[],[],[90],[90],[90],[90],[],[],[],[],[],[],[90],[90],[90],[90],[90],[90],[90],[],[]
From the sample mapping perspective it looks the following:
[0],[1],[2,3],[4],[5],[6,7],[8,9],[10,11],[12,13],[14],[15],[16],[17],[18],[19],[20,21],[22,23],[24,25],[26,27],[28,29],[30,31],[32,33],[34],[35]
Instead of samples 4, 14 and 34 - actually sample 0 is played.
Wonder if I can specify the same sample twice with two different indexes, to keep the amount of samples in all groups the same all the way along.
Absolutely Agree! There is also the EXS File Format that is similar. It defines mapping audio files to note ranges and supports layering for velocity thresholds but has many other features such as articulations. I don't think Orba can support articulations but maybe. Think about a saxophone that plays clean notes as you play but adds growl as you radiate. This can be done externally (MPE) for example with the GeoShred Preset.
This could potentially be done internally if you could assign two samples to the same range and use a controller to blend between the two.
I'm currently piecing together parts of code I need to create a Python script. This script will take a reference to a folder of .wav files as input. It will then sort the wavs in the folder based on tokenized pitches and velocities and generate the <SampleSet> node. I should be done by next week but haven't had much time. I'd like to build several Presets to work out the process. I'm planning to share the script in a new Custom Preset Forum I'm going to start at the same time.
What I am thinking of as a kind of theoretical possibility - there are tons of SoundFont instruments out there in the wild (SF2). Literally, gigabytes.
SoundFont is somewhat similar to what we have got in orba2 - couple of samples and their assignments to notes.
Could be an interesting challenge to be able to do some converter from SF2 to orba format.
Maybe these SF2 instruments are not that impressive compared to the modern Kontakt libraries - it is till a big legacy library of sample based instruments, that are not that much heavy on the sample size, as SoundFont comes from the 90th era, when people were limited by their PCs the same way as we are in Orba2, and SoundFont first of all was developed as a way to override standard midi bank sounds on ancient audio cards and stuff.
While converting beloved samples by hand to the Orba presets is still quite cool, possibility to generate presets from SoundFonts could be a giant leap ahead, by providing thousands of already existing sampled instruments via only one tool.
I don't think there are really any standards for UUIDs that I can spot from Artiphon.. In the end, it doesn't matter as long as they are unique.. Even that doesn't matter so much since it seems like app.properties seems to handle duplicated UUIDs (think collisions/binary trees).
One point to mention is that the UUIDs they don't have to be correct (they are never validated by the app.. at least for now), so there is no need to update them during development.
The Common folder idea just lets you drag one folder into place and it will merge everything into your Artiphon Library. Otherwise, those who want to install Presets will have to drag in 3 folders into Common. Just trying to make it simple for non-technical people who just want to enjoy new sounds but not make them.
>> I'm curious what you used to generate UUID for the .artiPreset file since it contains the UUID in the file itself?
Not sure at this point, but most probably I used md5sum of the main part of the preset name.
Like {BlaBlaBla}_{md5sum(BlaBlaBla)}.artipreset
The same as for wav files that was {abc}.wav -> {abc}_{md5sum(abc)}.wav
---
Mangled it by hand when could not replace old samples with new versions at some point, being unable to remove old.
---
If we want to write down a guideline for safe UUID generation, we might think big, like what if hundreds of presets would be generated this way. And here it starts to be interesting.
As for wav files - initially I've seen two ways here - calculating md5sum for the file content, or for original sample filename without uuid.
What is better depends on anwser on the question "do you really expect a new uuid each time when you modify a line in xml or update sample?" My answer is no, as I during development I update preset and samples in place and want them to have the same names each time, therefore I would prefer generating uuid from filenames.
But both of these methods might generate already existing md5sum uuid, and who knows what side effects that could have.
One method fails if you use same favorite sample for different presets, another will fail for the same original filename - and generic stuff like "shaker.wav" original sample appearing during different authors preset generation is quite probable
I would suggest using combination of subDirectory name + original_filename as a seed for checksum, like md5sum("PanDrum:D3ppf")
Same issue with artipreset uuid - main preset name can be the same for different instruments. It could be PanDrum for lead, PanDrum as drum.
Therefore i suggest Instrument_type+presetname, e.g. md5sum("Lead:PanDrum")
>> I noticed that your folder in the SamplePools doesn't have a UUID but it appears to be standard for the User folder (see what happens when you use the app to make a custom sample preset).
I did not notice any problems with that yet, but still better to do the same as Artiphon does, so it makes sense. Will follow this convention next time.
>> Also I think it will be best to wrap everything in a Common folder so that one can simply drag the Common folder into the Artiphon folder and install in one action
I do not see nor benefits nor downsides in each of the approaches particulary, but it will be obviously better for everyone to follow one single convention for the custom community presets packaging, to unify installation. You preset was first, so let's do it your way, and start with Common folder.
Will follow this as well.
@Ignis32
I had a chance to download your FreePatsHang Drum Preset and play with it a bit. Its Nice! I really like the muting feature and it seems to have some basic velocity that the notes get louder with more velocity. :) A few packaging suggestions.. It looks like most of the Preset images are 500px x 500px (but it probably doesn't matter since your image worked). I noticed that your folder in the SamplePools doesn't have a UUID but it appears to be standard for the User folder (see what happens when you use the app to make a custom sample preset). Also I think it will be best to wrap everything in a Common folder so that one can simply drag the Common folder into the Artiphon folder and install in one action. I'm curious what you used to generate UUID for the .artiPreset file since it contains the UUID in the file itself? I just grabbed the MD5 of the file with UUID="" and then once I had the hash value I inserted it back into the file.
I'm going to start a new Forum on the weekend: Orba 2 Preset Makers Forum. I think there is a lot to discuss there and still many things to figure out. I have lots of theories to discuss.. For example Drum Presets seem to support bends and flams :)
I was wrong about samples format, Audacity lied to me, making some underhood conversion that I did not ask for. All that white noise was because I used 32bit float that Audacity showed me, and samples started working when I accidentally exported them in a correct format.
Actual format for the Orba2 samples is PCM signed 16-bit little-endian 48000hz. as shown by https://www.metadata2go.com.
---
Sorry in advance for any people who will read my earlier post with invalid information that I cannot edit.
Thanks, I'll take a look at the samples to see if they are recorded low. There might be some volume related attributes too for me to look at. The samples I found were recorded at 5-7 levels for each of the notes they recorded. So the ones at lower velocities are naturally quieter. I may want to try to normalize them a bit so the more quiet samples are closer to the louder ones.. Who knew developing a good Preset would be so much work.. I guess that's why Artiphon partnered with another company :)
As far as I remember, I'd installed it with an app, more or less without problems.
BTW, I'd played quite a lot with your preset today, as it is cool. And it feels like it is a bit quieter than other presets around - had to set volume on max and reduce volume for others, to hear it in a mix.
Chris Hernandez
Hi Artiphon,
Any updates on whether/when there will be added functionality to the Orba 2 app allowing for user-customizable drum presets? I realize there are only 2gb of space available, but would love even just 2-4 customizable preset slots on the desktop app where I could assign all 9 keys. I primarily use my Orba 2 for on-the-go songwriting, and having a drum kit that matches the sound(s) I'm going for would be huge.
I realize that in order for the functionality to fully transfer on iOS, the user would probably need to send the drum sample files with unmodified file names to the associated preset folder on their phone. I've already done this with custom bass presets from OrbaSynth and I don't think it would be a problem for anyone with mid-level technical prowess. I think this feature would exponentially boost the value of the Orba 2 for anyone interested in quick, on-the-go production.
I'm about to write another request/problem I'm having with OrbaSynth, which is otherwise incredibly useful from a production standpoint. Planning on making a youtube review video as well. Thanks for keeping the updates coming, super excited for what's to come!
2 people like this idea