I recommend comparing the Tilt Lead SeekerData against the Weird Lead SeekerData. I don't remember what I did.. I was just noodling around and stumbled on the weird behavior.
I was puzzled when I was trying to find out what caused the pads to split. I couldn't seem to recreate the effect, and the only value that you'd changed was the same one I was using for pitchbend; 32 to 30 in this case IIRC.
I finally realised that the difference was the starting preset. If you swap out the SeekerData in the Tilt Lead preset, you just get the pitchbend. But if you swap it out in any of the other standard Lead presets, you also get the weird pad-split behaviour. So, something else on the to-do list is finding what's different in Tilt Lead compared to the others that causes that.
Another observartion is that the only difference between 1981 and your weird pad-split-pitchbend patch was that single SeekerData value. I usually keep the original Modifier/Seeker pair from Tilt Lead intact, but if you simply swap that one seekerData value out in one of the regular patches you get a different pairing with the corresponding ModifierData entry.
Having said that, the only difference in this case is seekerUuid, and after my last experiments with that I'm not convinced it's doing anything anyway. But it's worth bearing in mind that some of the ModifierData entries among the Lead preset gestures are different, and might also come into play when fiddling other Seekers. (In this case, Tilt Lead has a standard/basic ModifierData entry which still matches the other examples like 1981.)
...I just found that whether you swap just the one seekerData value or the whole Modifier/Seeker pair into a regular Lead preset, you still get the pad-split behaviour. So there's something else about the Tilt Lead preset that suppresses that.
Tilt Lead is quite minimal from an XML perspective, so maybe the Seekers/Modifiers are not totally distinct and there is some overlap?
...quick note about the "weird" patch; it's slightly more complicated than I realised.
If you touch and bend, it goes up and down a tone.
If you touch and cross, it drops three semitones.
If you bend after crossing, it jumps back up the three semitones at a slight angle, then continues to bend up another tone, and down a tone.
********************************************
Looking at differences in Tilt Lead, I previously mentioned that it had a...
<SynthPatch>
</SynthPatch>
...pair, while the others were't closed. I don't really like them not being closed. I tried closing one, not expecting it to make a difference, but it did seem to; it seem to cancel out the weirdness. At one point I just got a vibrato from sideways movement that I wasn't really expecting.
But the App likes to rebuild stuff according to its own ideas. If you delete a standard preset and run the App, it puts it back. When I added a closing </SynthPatch> to one of the Lead Presets that was missing one, it seemed to kind of dumb it down, like I say; but then by the time I'd opened a different patch and then opened the newly "fixed" one, the </SynthPatch> line had gone again.
It stays put in Tilt Lead though, because the App likes it how it is.
I don't really trust the dodgy XML or the App's propensity to mess around with it. In future I might just work with renamed presets that it doesn't know about and hope it leaves them alone.
...actually I think it still tinkers with newly named patches too. Dunno, it's slightly confusing. Maybe it doesn't matter for now.
I just tried deleting a bunch of the standard Lead presets, then running the App and quitting it again to let it rebuild them.
The synth patch definition for "1981" ends with:
<Compatibility audioEngineMajor="1" audioEngineMinor="4" samplePlayback="0"/>
</SynthPatch>
...but most (all?) the others seem to be missing those lines...?
Maybe the opening <SynthPatch> only needs a closing pair if it contains an additional entry, like this one, but since Artiphon didn't implement sample playback it doesn't do anything anyway.
Tilt Lead has that extra entry too, so that explains it.
<Compatibility audioEngineMajor="1" audioEngineMinor="0" samplePlayback="0"/>
</SynthPatch>
I expect I imagined any change it made and the difference is elsewhere.
I've always been aware of the "you have to rename it" thing, but I've only just realised this is where it comes from. (?) The App automatically "repairs" any of the standard presets. If you edit "1981", then open it in the App and quit it, you'll find it back how it started. But if you work with differently named copies that it doesn't know about, it leaves them alone and the edits remain.
(...and I take it back about the dodgy XML, the App devs clearly understood XML syntax better than I do, I'll give them that...)
It's the Vibrato Modifier/Seeker pair, corresponding to the gestureUUID beginning 38ca5c83, that introduces the split pad weirdness when combined with the (Tilt) pitchbend pair.
(I don't think the value of these gestureUUIDs is particularly relevant, but it's a useful handle for referring to the pairs; I usually have the "Ian repo" utility list open as a reference.)
I guess Pitchbend and Vibrato tread on each other because they're both trying to change pitch. Without the other pair, both work as expected.
I hoped vibrato range might respond to the same value in the seekerData string that worked for pitchbend range (no. 23), which it does. By changing it from the standard value of 31 to 39 in Grapefruit, as in the attached preset, you get a vibrato range of three semitones across a pad. However, there's a catch when you begin to increase the range...zipper noise, stepped modulation, which kicks in fast.
With slow, careful finger movements, you can hear a fairly gradual change, but with brisk movements with this pitch range it moves in a series of jumps; it's probably hitting the limits of the sensor's ability to interpret the data.
The two-pitch effect of the "weird patch" is probably connected with this; I think it's extreme zipper noise that jumps straight from the smallest value to the largest.
I'm still wondering how vibrato and pitchbend clash to produce this strange combined effect. Perhaps the effect of the two lots of seekerData is somehow cumulative.
Here's the 16 semitones that I was imagining. NOTE: Orba App must have Pitch Bend Scaling at 25%.
@BJG145 On closing </SynthPatch>. These do not need closing tags. Look closely and notice how the opening tag ends with "/>". There is an XHTML standard for non-container tags so if there is no content in-between opening and closing tags, then the opening tag can end with this special ending. When a patch introduces content (i.e.<Compatibility audioEngineMajor="1" audioEngineMinor="0" samplePlayback="0"/>) then there must be a matching closing </SynthPatch> tag.
From the internet:
I'm wondering how Tilt can be assigned to Pitch in some cases or to other synth params from Orba Synth? I noticed that loading Tilt Lead in OrbaSynth does not pitch bend.
>"How does the SeekerData bind a gesture with a control? I'm thinking index 1 because its unique across all seekerData"
Yep - we have remap. Changing index 1 for a tilt-bend-only preset from 35 to 41 (Shake CC) gives you "Shake to bend" (attached). It reponds to pitch scaling.
(They're not quite unique; Tap/Press and Move/ShakeCC share this index. I guess it's because the action is the same.)
Andrea Mannocci
This thread is intended to gather the feedback of Orba tinkerers.
27 people like this idea