Good thing I took notes, it’s either Touch OSC or Morph Wiz!
I suppose you would think of it in terms of node->module->rack, such that you could always bring the racks back into Audulus for use, but they would be locked in a way – although maybe still front patchable.
TouchOSC allows you to build custom control surfaces for both OSC and MIDI on iOS. This is a layout I did for Audulus
MorphWiz is an older iOS Synth app that’s recently been updated for iOS 11. Kind of a different UI, I think you’d like it
Ah perfect, I just bought TouchOSC
It works nicely with Audulus using MIDI and is a way to get multi-touch support for Audulus. There’s a thread on the old forum if it’s still there. Very stable using the TouchOSC bridge app to send MIDI to Audulus on the Mac. Also works running Audulus in background on iOS, but I found you had to launch Audulus, load the patch, switch to TouchOSC, move all the controls then switch back to Audulus to get the link established. Apparently Audulus has some problems with MIDI while it’s backgrounded. I let Taylor know and hopefully that will resolve itself with the MIDI update. If knobs and toggles send as well as receive Midi, TouchOSC would sync with the knobs in Audulus. I’ll dig out the template and patch tomorrow and post them
I posted the files in a separate thread: Using TouchOSC as a MIDI control surface for Audulus iOS
I think to be effective, as an AU the Audulus patches will have to be more GUI oriented rather than focused on flexibility and programability in the AU environment itself.
Many synth apps have taken the approach of having a more limited set of features in the AU with the idea that users can create their presets in standalone mode or IAA mode.
At the very least I would think there’d be an option to make efficient GUI oriented with minimal controls versus a mode where the patch is similar to standalone or IAA mode currently.
Fancy DIY SVG graphics can be a real drain on patches if you’re not careful. It’s the details preserved in the SVG files that will drag you down which can be seen in terms of how large the files are and even if they seem small compared to jpg or png files in terms of size, the workload for Audulus can grow very quickly.
Here’s a very frivolous patch with just one knob that illustrates what can happen when you don’t address these issues.
GlobeKnob.audulus (1.2 MB)
One idea would be to pixelate the graphics a bit
I thought vectors were more efficient than rasters.
This is where I might learn something, but one of the issues right now is how the latest iPad Pro runs its GPU. So it may be efficient for realtime scaling, but if you have a locked face plate…
I am tempted to have some hair-brained theory but I probably should avoid that. Maybe you could have low res vector?
It depends on how many vector points are in the SVG file. I’ve been experimenting.
The resolution of vectors is the same, the difference is the complexity so it doesn’t matter how big a given icon is in terms of screen space.
Well, I wouldn’t mind if the Audulus AU3 had a highly pixilated icon mode if it meant things running more smoothly.
Having a pixilated icon isn’t really the way to deal with vector graphics. The designers know how to figure out how to stay within reasonable limits of complexity and still have it look good.
The average person still focused on an analog dots per square inch perspective may still create large SVG files which are much smaller than png or jpg files yet can cause huge problems because they have thousands of vector points to process versus hundreds. Even the performance of compression algorithms will benefit from having less detailed graphics.
In some respects it’s similar to the spline issue where higher sample .wav file sample rates as script input created too many points and overloaded patches with them versus down sampling and have hundreds.
AdulusBMvect.audulus (240.6 KB)
Audulus SVG Comparisons
|5 kb png||187 kb svg||47 kb svg||3 kb svg|
|scale 50x50 px||Original to SVG
|Original to SVG
from good svg
won’t render in
due to basic
I think the idea is that you’ll eventually be able to click on a knob or button and have it show up as a control, like you can in any plugin in Live, for example. So you wouldn’t have to have the actual plugin window open to control it.
I don’t know if we’d made a version that was limited graphics for plugin only. It sounds great for making a single module, but what if you’re playing a huge complex patch? How does Audulus know where to put all the controls so it’s not a jumbled mess?
I believe that when being used as a plug in, multiple discrete instances are what’s being asked for. Also, I think they are asking for the option of a no graphics mode, but its not mutually exclusive with having a single instance with all the graphics.
I’m not sure. I have plenty of ideas, but none that don’t seem like they would either be too much hassle to program or would require library modules to have associated labels.
Here’s what I would like for an AU mode (not against other play modes). | have ideas about GUI screen switching which I will present in a different post which will be compatible with GUI AU Play Mode.
GUI AU Play Mode
|Touch Control||knobs triggers||only these controls|
|MIDI Setup||MIDI control||setup mode to assign MIDI to controls|
|Preset||Patch MIDI||Recall patch with MIDI assignments|
NOT in GUI Play Mode
|Edit||It’s preset based so no changes|
|Objects Move||Only controls and displays move|
|Subpatch||Will not be opening subpatches|
It seems like the idea of exporting is key. You could maintain the patching environment of Audulus, but you could also go down the road of having an exported version of a patch that was more efficient with the front panel locked? In this scenario you are building AUv3’s using Audulus, not running Audulus as an AUv3; however, one does not preclude the other. It just means that you can get into using multiple Audulus effects and synths in an iOS DAW like Beatmaker 3 or Cubasis. In my opinion, the workflows for this sort of setup have been too overlooked by Intua, Steinberg, and others. There is a difference between patching modular and performing modular.
This episode had some great discussion about performance based modular. And while I am not primarily interested in “performing,” I would like to be able to reliably work through building tracks with as little haunting for editing, etc. as possible.
No, I get that - but say that one instance is a single module like an effect, while another instance is a large patch, like a synth with a lot of modulation and an arpeggiator?
The “no graphics mode” would just be not opening the Audulus window. That way, the graphics wouldn’t run. You wouldn’t be able to manipulate the knobs directly, but that’s what the automation would be for.
Why not just use the lock mode? Are we talking CPU savings from reduced graphics? I’m not sure @Taylor or @balph would want to write an entirely different engine for the AU graphics. It also would mean you’d have to have two separate versions - one that you’re talking about that is static and one where you can still patch in it. And as AFAIK, you’d actually have to duplicate the library for both, which would take up at least 140mb more of space.
You’ll never be able to export to an AUv3 for iOS. If we made a version of Audulus that spat out plugins, it would be a more expensive developer version.
And just so we’re all clear, the AUv3 plugin will allow you to instantiate multiple instances of Audulus in different tracks. It seems like people are asking for a way to pack Audulus as a separate plugin so they can do this, but you don’t need to pack your patches into a separate plugin - you just open multiple instances of Audulus AUv3.