This deserves its own thread!
3 Likes
I have two suggestions which I think would really help, one only for iOS (using on ipad pro).
Also agree that svg options would be nice.
On iOS reusing my own patches could be a lot lot simpler. Right now theres the iCloud library option but everything is saves into there. So I have a subfolder for my patches which I reuse. But this means that each time I load one of these from another file I have to first press BROWSE then my subfolder and then the patch. If there was a way to save SOME patches into my own library this would be great. So instead of icloud library it would be a user library with only what I need.
The big feature Im missing and would love to see in Audulus 4 is passing functions (expressions). It would eliminate a lot of redundancies and in cases where I use my patches it would make things a lot simpler to do. For debugging or experimentation this would be amazing. To clarify I mean expressions as inputs.
This is definitely a feature we’re working on 
It was just too complex to allow root access to the default folders when we first rolled that new structure out.
Can you explain this a little more? I’m not sure what you mean. What would need to be different about the expression node to work as an input? You can double click or tap on an input and an expression node will be created, if that’s what you’re looking for.
You need to use the MIDI input module or the keyboard node. The MIDI input module is a rehousing of the keyboard node with some extra bells and whistles, so to change the input channel you just need to go inside the module.
Here’s more info about the keyboard node:
Thanks for the reply!
About the expression input:
Suppose I have a subpatch that I created. This subpatch uses the expression f=x=sin(x) 3 times. Im working outside this patch and want to replace f with another expression and hear the result. If I could input an expression into the subpatch (which would take the place of sin) I could do that. It would also be good that then I could see the expression without openning the subpatch.
Can you make a little example patch of this? I think it’s actually possible to do what you’re asking for, but in a way that you might not be thinking of.
Also by f=x=sin(x) three times do you just mean f=sin(sin(sin(x)))?
And I don’t think there’d be a way to be able to see an expression on the outside of a patch unless it’s physically outside of the patch. Otherwise, modules that have hundreds or sometimes thousands of expression nodes would be difficult to manage from a UI.
No sin(x) once. I’ll post a file. I might be explaining badly.
1 Like
Yes! thats great. Didnt think of that. Not a feature request anymore 
1 Like
I’ll pile on a little to the bitwise operators request. In my experimenting with scales, I began looking for binary operations on decimal values, without lots of patch building. (For scales, I’m assuming LSB would be the tonic of the scale, per the quantizer patches I’ve studied and built myself). Apart from musical scales, you never know what someone will do with a new tool.
1 Like
What would I really love?
Some type of “external” element option, where code (an audulus file?) residing in a separate file could run, take inputs from the node and outputs from the node. I could see a huge productivity and maintenance improvement. I’ve always been a big fan of classes.
Perhaps you’d have the ability to set the target file in the node (as you do for a random seed at present). Inputs and outputs it finds in the file would be rendered on the UI, to be moved around in the the normal edit UI fashion.
Maybe a search hierarchy in settings for finding external elements, starting with the same folder as the using project.
To invoke , you could have a option for the “create” command, when choosing patches you’d have the options “add as a copy” and “add an external reference”.
Would there be a “collect project”, as you get with layout software? How would one approach that? I imagine you’d want such a command for publishing or archiving, where you keep your libraries in one place for developing projects.
3 Likes
Part of the design philosophy of Audulus is to have every patch be self-contained. This is definitely for simplicity and file management’s sake.
You could do what you’re asking for by using Audulus as an AUv3 and pass info from one instance to another, but AFAIK you wouldn’t be able to pass it backwards in a feedback loop.
One thing we did talk about having were teleport nodes that act as a sort of internal “wireless” broadcaster and receiver. So you could send a signal to a teleport node inside a module to a “channel 10” and all other receiver teleport nodes set to channel 10 would receive that signal.
1 Like
That works pretty well in Max/MSP. I would say that some way of visualizing the connections would be important, as would copy/paste and level considerations.
Can you elaborate this a little more? I was imagining the node being sorta like an input/output node with a channel select input (so it could be automated/LFO’d). Not sure what you mean about copy/paste though? Like if multiple signals were being sent in together to the same channel? I’d imagine they’d just sum, right?
So if DAC and ADC nodes work regardless of what level of visibility they have in the node so an ES-8 specific module might have several outputs not visible when looking at the top level of the patch. If I have 2 DAC nodes their outs are summed to the output module, and if I have 2 instances of an ADC then it will receive the input signal at both locations. Now take the example of a teleport node. If I have a big complex generative patch that uses teleport nodes that are buried deep inside a module, accidentally using the same address for sending and receiving can inadvertently cause problems, copying and pasting seems like a really good way to create said problems.
So easily seeing what you are teleporting your signal to is kind of important to debugging such a situation.
2 Likes
What would the UI for this look like? Like, what does it mean to “see” what you’re teleporting it to? There could be multiple destinations, as well as multiple signals feeding into the same channel.
What would you need other than a scope to figure out of the channel is free or not?
1 Like
One approach might be to restrict teleporting nodes to the same level of abstraction, then you could basically just make connections visible and invisible.
You could also just show where connections exist with highlighting in some way. They way you can see how much CPU is being used, you could toggle to a view where modules would display the teleported connections within them.
Those are the two first ideas that pop into my head. I’m sure there must be something that is less of a hassle to animate.
But this would limit the usefulness of the teleport node for the sake of a kind of clarity that could be made with just text notes as to the destination or origin (or even within the menu itself?).
Here’s one way I could see this being useful:
Say you build a library of modules around the teleport nodes. Channels 1-16 could all be dedicated to clocks from a master clock. That way if you want to use a module that has a gate input, you can just have a selection knob that selects between channels 1-16 as the input and you can, just by modulating that knob, get a rhythm. You could do this now, too, but you’d have to have 16 inputs on the module to accept all the different variations, or duplicate a clock divider circuitry inside of it, leading to more CPU.
Perhaps what you’d really rather see is instead of highlighting the connections inside a patch (which, because they wouldn’t be placed at the same level of abstraction or grouped in a way that makes it easy to read where the connections are going) you could just get a menu when you tap on the teleport node that lists all the names of each channel, which you would assign/rename at each origin node.
Because it matters less actually seeing the physical connection and more knowing exactly what the connection is called, right?
The big issue I see with the “teleport” is basically the same as @robertsyrett’s. Without some way to limit the scope of a teleport, it would make sharing modules that use this function difficult. If you built a module that used a channel and someone else also built a module using the same channel for a completely different function, putting them in the same patch would cause problems. If the teleport nodes were several levels down in each module, it might not be apparent why things weren’t working the way they should. By including a “teleport” you could be breaking the self-contained nature of a module. I would strongly suggest that nothing internal to a module be exposed other than the elements explicitly included in the UI. Forty years of programming experience tells me that this is a bug waiting to happen. 
1 Like