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 :)
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.
@ignis32 I really like what you've done there!! If you don't mind I'm goin to add your settings to the PanDrum preset I'm working on too. I still haven't figured out the pitch math for correcting 44kHz vs. 48kHz. I thought it would be as easy as multiplying all my pitches by (48000/44100) but it didn't seem to work. I may just try to convert my .wav files from 44kHz to 48kHz and hope the loss is not too noticeable.
>> 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.
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.
Sounds promising, cheers...
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.
@subskybox that is incredible and exactly what I was hoping could be done! Thank you for sharing the example video, so cool. I also hope Artiphon takes note of this and implements a structured way to do this that integrates with their apps - particularly the desktop app, though I imagine they'd probably do both if/when they did.
I have a super rudimentary understanding of Python, but would totally be interested in looking at what you did if you're interested in sharing. Or even the code with the most important sections commented out/explained a bit.
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)
By maximum size I mean maximum known working size, not some sort of limit I'd bumped into.
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.
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.
Had some hopes for User samples pool but it seems like the same happens for the presets created by in-app samples recording:
Here I am creating a record:
[0001352758]+9258 [t:MessageManager] (SampleAuditionController) -> exiting audition mode.
[0001352758]+0000 [t:MessageManager] (SampleImporter) -> importMelodic: C:\Users\ignis\AppData\Local\Temp\Record\2022-11-20-16-36.wav
[0001352762]+0004 [t:MessageManager] (SampleImporter) -> starting sample import: 2022-11-20-16-36_da12fe55bd7747d4ba4e4abf4edb198b
[0001352762]+0000 [t:MessageManager] (SampleImporter::createPatchData) ->
[0001352762]+0000 [t:MessageManager] (SampleImporter) -> Setting patch name to 2022-11-20-16-36
[0001352768]+0006 [t:MessageManager] (SampleImporter) -> Saving preset to C:\Users\ignis\Documents\Artiphon\Common\Presets\Lead\2022-11-20-16-36_da12fe55bd7747d4ba4e4abf4edb198b.artipreset
[0001352776]+0008 [t:MessageManager] (ViewController.cpp) -> going back from Save Preset Dialog
[0001354036]+1260 [t:MessageManager] (ViewController.cpp) -> navigating to Ok/Cancel Dialog
[0001355256]+1220 [t:MessageManager] (ViewController.cpp) -> going back from Ok/Cancel Dialog
[0001362422]+7166 [t:MessageManager] (ViewController.cpp) -> navigating to Preset List Actions
[0001363168]+0746 [t:MessageManager] (ViewController.cpp) -> navigating to Delete Dialog
[0001364200]+1032 [t:MessageManager] (ViewController.cpp) -> going back from Delete Dialog
[0001385435]+21235 [t:MessageManager] (ViewController.cpp) -> navigating to class MetadataViewerDialogContent
Here I am uploading it to Orba:
[0001386236]+0801 [t:MessageManager] (ViewController.cpp) -> navigating to Progress Dialog
[0001386255]+0019 [t:MessageManager] (TemariComm.cpp) -> queueFileOpenForWrite /SamplePools/User/2022-11-20-16-36_7052271854584d9f8a6600d7553aeeac/2022-11-20-16-360_85e0b8ac7ecd4876b9b5f5a35b8a44b2.wav
[0001386257]+0002 [t:MessageManager] (TemariComm.cpp) -> queueFileWrite
[0001386257]+0000 [t:MessageManager] (TemariComm.cpp) -> queueFileOpenForWrite /SamplePools/User/2022-11-20-16-36_7052271854584d9f8a6600d7553aeeac/2022-11-20-16-361_0706e860bcb8447e9220750b790f262c.wav
[0001386257]+0000 [t:MessageManager] (TemariComm.cpp) -> queueFileWrite
[0001386257]+0000 [t:MessageManager] (TemariComm.cpp) -> queueFileOpenForWrite /SamplePools/User/2022-11-20-16-36_7052271854584d9f8a6600d7553aeeac/2022-11-20-16-362_4b1baaad191645de914d605446819db5.wav
[0001386258]+0001 [t:MessageManager] (TemariComm.cpp) -> queueFileWrite
[0001386258]+0000 [t:MessageManager] (TemariComm.cpp) -> queueFileOpenForWrite /SamplePools/User/2022-11-20-16-36_7052271854584d9f8a6600d7553aeeac/2022-11-20-16-363_9c90ac360c914fa9bb7237d38293b0b8.wav
[0001386258]+0000 [t:MessageManager] (TemariComm.cpp) -> queueFileWrite
[0001386258]+0000 [t:MessageManager] (TemariComm.cpp) -> queueFileOpenForWrite /Presets/Lead/2022-11-20-16-36_da12fe55bd7747d4ba4e4abf4edb198b.artipreset
[0001386259]+0001 [t:MessageManager] (TemariComm.cpp) -> queueFileWrite
[0001390126]+3867 [t:MessageManager] (TemariComm.cpp) -> assigning to mode Lead preset: 2022-11-20-16-36_da12fe55bd7747d4ba4e4abf4edb198b.artipreset to slot 1
[0001390137]+0011 [t:MessageManager] (ViewController.cpp) -> going back from Progress Dialog
[0001390195]+0058 [t:commsEventThread] (TemariDeviceInstance) -> skipping preset scan
[0001390200]+0005 [t:commsEventThread] (TemariDeviceInstance) -> skipping sample pool scan
[0001399046]+8846 [t:MessageManager] (ViewController.cpp) -> navigating to Preset List Actions
[0001400204]+1158 [t:MessageManager] (TemariComm.cpp) -> assigning to mode Lead preset: 2022-11-20-16-36_da12fe55bd7747d4ba4e4abf4edb198b.artipreset to slot 1
[0001400217]+0013 [t:MessageManager] (ViewController.cpp) -> going back from Preset List Actions
[0001405655]+5438 [t:MessageManager] (ViewController.cpp) -> navigating to Preset List Actions
Here delete happens, but only artipreset is removed:
[0001406580]+0925 [t:MessageManager] (ViewController.cpp) -> navigating to Delete Dialog
[0001407533]+0953 [t:MessageManager] (TemariComm.cpp) -> TemariComm::queueFileDeleteFile deleting file on the orba: /Presets/Lead/2022-11-20-16-36_da12fe55bd7747d4ba4e4abf4edb198b.artipreset
[0001407534]+0001 [t:MessageManager] (ViewController.cpp) -> going back from Delete Dialog
[0001407583]+0049 [t:commsEventThread] (TemariDeviceInstance) -> skipping preset scan
Basically, it look like everyone who uses custom samples functionality will run out of space without ability to clean it.
...looking at the .artipreset file for Horror Drums, sampleIndex 0-7 corresponds to pads 1-8, while sampleIndex 8 is Bump. Not sure how you access 9-13.
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