Ahh good points - maybe only teleport within a subpatch then?
These are prescriptive implementations, how is a noobie supposed to know all that?
I think this will still be great, and will more or less remove the need for reverse vias.
I think the teleport node could be useful as long as you restrict it’s scope to senders and receivers at the same sub-patch level. That way all the senders and receivers would be visible and you could import a module without having to worry about whether it contained transmitters or receivers. Typically with this kind of messaging system you are restricted to a single transmitter for a given channel, but summing multiple senders could also work.
I reported a (kind of) « bug » in the behavior of the poly mode of the keyboard a few months ago (June 21), and @biminiroad said that it had been fixed in the latest beta.
The thing is that now I really like this « bug »… I know it’s not how most poly synth work on the iPad but I really like that you can play n notes at a time and then play n other notes and have every voice retrigger, it’s a very nice effect. And it works for whatever n smaller than the poly count.
In other synth, once you set the voice number to (say) 4, then you can only have this « all voice retriggering » effect when playing 4 notes at a time. If you play 3 notes chords it won’t retrigger every voice nicely.
So now I am basically requesting the current behavior to still be an option in next releases… (I am aware that it’s close to the opposite of what I requested before…)
Definitely having more options for voice triggering would be great! There’s definitely even more options like high vs. low priority, last triggered, etc. that we can incorporate. Thanks for the idea!
I saw talk of adding a continuous xy pad, looking forward to that. one thing i thought would be cool is some sort of “gesture recorder” for the xy pad. a way to record a performance on the xy pad, and have it playback the sequence, freeing the player to mess with other sound shaping parameters. i feel this would be a great way to utilize the potential of the touchscreen to create an intuitive tactile sequencer based on gestures. the ios app samplr, for example, makes incredible use of this idea of “gesture recording” and i feel that it is one of the main reasons why it is often bought up in “best ios music app” conversations.
@kin.sventa Here you go!
We can maybe do something in the future that’s more global and doesn’t require a module, but your request inspired me to make a CV looper. There’s also an XY pad version there for you to mess around with!
wow thank, amazing. thank you so much for this. gonna try this out right now
this is so cool to hear ! i just played around with the cv recorder. so much fun. the idea of a cv looper is really exciting. i’m imagining a way to record a cv sequence on an xy pad then be able to transpose it, speed it up, slow it down, reverse it, scrub it, jump around it etc. this would be a dream come true.
When Audulus 4 comes out have be a separate release in the App Store. I don’t know how backwards compatible it’ll be, but it’d be nice to keep Audulus 3. I rather pay again than have to remake everything right away.
And I’d like to see a “pin down module and hide wires feature”. Maybe the boarder could change colour from grey to blue to show that it’s held down.
You’re able to do all of that except reverse it, and when you speed up/slow down, you start to lose fidelity each time you do it (try turning the time knob after recording you’ll see what I mean). If you want to transpose it you just need to use like a Modulation to Octave control after the XY pad and modulate the offset control. I will create a patch example when I get back home.
Audulus 4 will be a new app, not an update, so yes you can run them side by side. You’ll be able to open Audulus 3 patches in 4, but not the other way around. When you open patches in 3, you will probably need to do some UI rearrangements, but they will otherwise be functional. It’s not a terrible loss since a lot of patches would be improved by new nodes that will be featured in 4, so it’s a good opportunity to reincent the UIs of old modules.
There’s a lock feature on iOS but I agree it would be nice to have in Mac as well. In future we’re going to try to make the two versions as close as possible, as this is what Apple is trending towards anyway.
What I mean is lock one thing, say a main unit, and leave everything else unlocked. That way you could still move aux units around it. And if it hid the wires at the same time it’d reduce things drawn on screen.