Are you looking to make patches like this?
1 Like
Any chance we could have resizable editable text fields for text and expression nodes?
1 Like
What we’re doing for A4 is when you click on an expression, a bar comes up at the top of the screen and you can type it in there. It’s as wide as you make the window so it’s pretty adequately long even for the longest expressions.
For text, I’m hoping we have some more options too. Would make it easier to write in-app documentation especially for iOS.
2 Likes
I recently dragged out my trusty bbedit, which has those nice features like autoindenting, parenthesis balancing, etc, etc, etc, to write and interpret more complex expressions. I’m not expecting all that in Audulus 4, but it would be nice if tabs and newlines were supported (I’m not certain they aren’t now) and were displayed in editing and in text display.
It could go without saying-- I’ll definitely be upgrading my Mac and my iOS copies to Audulus 4!!
2 Likes
Making the expression field wider is certainly welcome!
2 Likes
This in one of the main reasons I prefer to break long expressions into multiple nodes.
1 Like
True that, and it sort of self-documents. That one of the reasons I will use vias. It allows me to give my signals “show dog” names!
3 Likes
not sure this has been brought up before, but I’ve got a bunch of custom modules in my “toolkit” folder and I would like to be able to add them to any current patch more easily than Open file -> copy -> paste -> close file. I’d like to have my own modules in the right-click menu.
1 Like
Go to Audulus → Open Modules Folder → Drop them in there
This is what my right click menu looks like - you can put whole folders with organizational trees in there as well.
Something similar is coming to iOS - right now you have to navigate through iCloud to do a similar thing.
1 Like
oh of course! thank you, works great. I don’t need it as bad on iOS as I did on desktop.
2 Likes
2 Likes
The quad and stereo nodes do that now, I believe that @Taylor plans to expand on the idea in Audulus 4 and allow for more than 4 channels.
2 Likes
Knowing @eall123 comes up with when patching, I think what he’s asking for might be more like multiwire routing, where you can select multiple individual wires and route them to multiple inputs. If you had a 32 to 32 poly chain, you’d still have to wire 32 inputs and 32 outputs ultimately, even if they’re carried in a poly chained wire. I’ve talked to Taylor about the scheme I think eall123 is describing - basically you’d select the wires somehow and move them as a group, and they’d just auto connect to whatever input is closest to them.
3 Likes
Bidirectional within a bundle, perhaps?
Maybe not. A bear to maintain, and we’re all used to separate ins and outs!
Piling on here! Can the sweep direction in a waveform node be reversible? Can it have triggered/free-running mode with a sync/trigger input and perhaps a reset?
I’m imagining a scenario where you want to trigger off some event, saving the resulting waveform for comparison with the next.
Another thought is an X/Y mode, used for generations to create lissjous patterns on oscilloscope for analysis and fun.
Oh, and just for grins an rgb mode that allows the waveform color to be set or changed on the fly!
We’re going to have a more fully-functioning scope that will work at audio rates and have typical options like trigger inputs etc. 
Color input is a cool idea! One thing we might bring in is the possibility to use shaders, which you could then use to make whatever kind of scope you wanted to, including other types of 3d imaging.
2 Likes
If knobs could be assigned meaningful identifiers, as you do in XML/html, I could see it as an easy way to “control at a distance” or apply presets to an Audulus project (via static values from a comma-delimited text file, or by addition of some “presets” node, containing the presets, into the project.
Maybe create a receiver node and a transmitter node, each displaying the assigned ID for clarity. Signal into the transmitter node’s input appears at the corresponding receiver’s output.
Duplicate receiver IDs would maybe behave as classes? Duplicate transmitter IDs would only work within the same patch. Maybe global scope yes/no option?
Hmm, all this reminds me of something I’ve already heard about that was being considered for A4!
2 Likes
Yeah I do feel like we need some kind of preset management for A4. You can’t just preset blast (in a good way) when you have to open up multiple patches. It would be amazing if we had some kinda UI node element that handled this that you could actually stick onto a standalone synth.
Part of a practical preset system would be determining what elements need to be captured as part of a preset. Knob and toggle settings would need to be included and also probably MIDI assignments. I’m not so sure about connections between nodes and/or modules. If you add connections to the preset list, you may as well just consider the patch file itself as the preset. I’ve given this some thought and it seems to me that there are a couple of possible ways to implement presets. One way would be to capture knobs, toggles, and MIDI assignments and provide a way to easily switch between sets. This has some problems since any editing to the patch could easily break an existing preset file. I think a more promising approach would be to provide a way to cache several versions of a patch (or even different patches) with a quick way to switch between them without having to close and open each file. The patch files themselves are usually reasonably small so the additional overhead of caching multiple files shouldn’t be too big of a problem. This way each patch file becomes a “preset”.
1 Like