As @biminiroad has explained, the only fundamental elements in Audulus are nodes. A patch, or module is a JSON file containing a list of nodes, their spacial positions, interconnections, settings (for knobs and toggles), etc. I can see some advantages to a more traditional library setup where modules are separates files that are “imported” at run time, but along with the advantages of single point updates, you have all the added complexities of dependency management, version control, and the need to ensure that the necessary libraries are actually present on the target device. As it stands, a patch is self-contained and so long as it is compatible with the current version of Audulus, does not require any additional resources. Unless there were a big performance gain (e.g. some form of pre-compilation), I think the advantages of simplicity outweigh the disadvantages. Some kind of automatic version stamp would be nice, but at this point every time you open a file (at least on iOS or macOS) it’s flagged as edited even if you have not actually made any changes.
That’s the way it should stay.
However, the “more traditional” libraries you’re thinking of are dynamically linked libraries (.dll, .so, .dyl). There’s another even older kind: static libraries. Those are embedded in an executable and only change when rebuilding it.
Of course, Audulus doesn’t have a separation between source code and executable. That’s why I suggested unique internal identifiers for patch nodes. They would make it possible to find all instances of a module and exchange them with a newer version at will.
The details are probably a little or a lot more involved, but that’s where I would start if I needed to do something like this.
I think one of the difficulties with a module control system is that often modules are modified depending upon the GUI users would like. This can mean controls can be shifted to different patches.
In terms of consistency, I think the current approach to standardize, document, and expand I/O practices has been very helpful.
More core modules which are less likely to have a need for modification as well as being widely embedded in the patches of users would definitely benefit from your proposed module ID system and a method for being able to globally exchange them for an updated version of the module.
Even for their own purposes, I can see how users could receive the benefit of module ID so that as they work on their own projects they’d be able to invoke or setup some sort of process where they could auto update their own patches and the users of their patches would be able to do so as well as this update system could be part of their patch distribution process.
Your suggestion of some sort of URL for this process makes a lot of sense. Audiobus app presets can shared with other users using such a system. The BitWiz app also allows users to share their presets (stack based sets of C expressions which generate audio frequencies using a similar system in the form of Tweets.
With Audulus, the ability to have a URL based patch mechanism would be similarly useful for users distributing and updating patches. The URL system could be integrated with other material such as performance presentations, tutorials, compositions, and patch documentation.
The JSON structure of Audulus patches might facilitate the development of tools for these purposes as well.
The current library is a static library of sorts given that there is no build process. I would agree that some form of automated version control would be nice, but I see some practical difficulties. Currently, scaling, layout and more importantly knob and toggle states are saved with a module. It would obviously be impractical to create a new UUID every time a control is changed or something is moved onscreen. Since both iOS and macOS automatically overwrite files dynamically you would have to have some mechanism that would analyze any file changes and determine if they required an update of the UUID. You would also need some way to reconcile sync issues when using iCloud for storage. It would certainly be possible to manually embed a version number in the file, and in fact an earlier version Audulus had version as one of a number of meta-data fields
I definitely would not want a system that automatically updates modules.
Forget about implementation details for a moment. From a user perspective, here’s what I want:
When a new version of Audulus is released and comes with some updated modules, I’d like a way to find all the places I have used those modules, verbatim or with modifications. Then, at my own discretion, I may want to exchange some old instances with the new version. Any automated help Audulus provided would be appreciated.
The same applies to my own or third party modules.
I understand what you’re asking for, but it seems like it would be a nightmare not just to implement, but even to use.
So you open a patch and it asks “Do you want to update X module?” And you click yes, and then what happens if someone upgraded the module, and in the process, deleted a knob then recreated it? To Audulus, it would look like a new knob, and it couldn’t resolve the conflict between the old version and new one if you had the knob connected to a wire in your patch or of course at a distinct setting.
I guess what it comes down to is this - if you want to update your patch with a new version of a module, is it really difficult to just replace it? And why do you need to update it if it’s already working?
This ultimately seems like a feature that would be best for maintaining the main module library, or for people who have built their own large custom libraries and want to update a single thing and propagate it across all their modules - not replace the module within a patch that is already patched and running and has to respect where wires are connected or what the knob settings are.
You got me. It’s hard to notice ones own preconceptions. I look at Audulus from a software engineering perspective, but that may well not be appropriate for its intended use and users.
@murmichel, Like you, I have a software engineering background, and find version control in Audulus to be a bit of a headache. I have a pretty large collection of modules I’ve created, and I very often find it difficult to track revisions. I have taken to embedding a version number internally as text within each module and also try to include it in the file name. This is, of course, a strictly manual process and isn’t always the most reliable. Often the U/I and other features of the module change as it evolves and in many cases replacing an older version of the module with a newer one would break an existing patch. Unlike many programming environments, it’s often difficult to create an “API” for a module that remains relatively stable. It’s a pretty fluid environment, and that definitely brings some challenges. Even so, I would certainly support anything that makes this process easier.
If the I/O connections for a module are the same and only the internal processing within the module has changed, it’d be nice to have a way to automatically replace the module. This could consist of a list where it goes through your patches and you can select whatever patches you’d like to do this auto replace on. There’d definitely need to be a testing process to work through how such a procedure should work.
If the new module has different I/O then it wouldn’t be straight forward about how to propagate such a change in patches that use it.
The benefits of such an optional system would be that users would be motivated to think more clearly about what sorts of I/O connections make sense due to the benefits of being able to easily update and track their own patches and also for the benefit of other users.
It would seem to be an extension of the process started with uModules.
Is there a way to associate colours with labels on the left hand side bar so that instead of it saying “orange” beside the orange dot it says “folders” or “new” or “unfinished projects”?
Also, I tagged some folders red, but they don’t seem to come up when I select the red tag.
Selecting the tag on the left only seems to work for files in Audulus. The folder tags do work in the files app. If you arrange by tags (selection at the top of the browse menu) the folders do get re-arranged. You can create your own tags by selecting a file (long press) selecting tags then Add New Tag. The tags don’t appear with the file name however, as far as I can tell, you have to look at either the tags or info sub-menu. They do appear to work in the sort. I couldn’t find any way to rename the colors.
Tap “Edit” up at the top, then tap on the name 
Not sure if this should go under a build request or whatever…It would be nice to have an oscilloscope. You can see them here on the Korg and the Zeeon softsynth.
Thanks… Didn’t see it. Too intuitive.
Duh 
Tried long press, slide etc. Didn’t think to try tap
I’ll have to start saying that
Audio rate oscilloscope is coming to Audulus 4. You can use this clever hacky one for the time being. Doesn’t work well to analyze FM’ing waveforms though.
Scope Demo.audulus (32.0 KB)
Maybe I’m blind, but WAVETABLES?
Thanks