Just updated with a no display input as well
1 Like
Looks like I downloaded at just the right moment!
1 Like
The display model is using the new clamped knob so you can modulate it as well. This is a case where out of range values would definitely cause unexpected results. Inputs on the no display version are clamped at 0-1.
1 Like
Just noticed something is out of place on the one display. Give me a second and I’ll fix it.
color mux-demux V1.1.audulus (89.6 KB)
2 Likes
I’m a newbie and a lot of the time it still feels like I’m flying blind. What would be very helpful is an audio rate oscilloscope. Additionally, a spectrogram, instant as well as over time, would be nice.
In my other life, I’m a software developer and I tend to think in modules and interfaces. Modules in Audulus are more like macros. They are copied and expanded to each place where they are used. That makes it difficult to update a module everywhere it is used.
The in-place “Help” for modules is not really helpful: It only says that it’s a patch node. I’d rather see a help message for the specific module.
There is already an item for AUv3 on the Megapoll, but I think it might apply to macOS only. If it applies to iOS as well, please clarify. If not, please add iOS AUv3.
1 Like
Both are coming in Audulus 4 
Tell me about it! Haha I still want to go through all of the modules and add node-by-node explanations of what’s going on and I have to do this all manually. Not sure what can be done to streamline “updating” a module after it’s been implemented in a patch without risking breaking the patch. Open to ideas though!
That is something I’m working on right now - if you see the Weekly Update I posted, what I’m doing is adding a ToC to the modules documentation which will help in the future for adding the help function that points directly to the module’s docs rather than the Subpatch node. However, you can actually enter the module and get an overview of what it does inside. It’s everything that’s there in the documentation minus the new tables I’m adding.
AUv3 is coming to iOS before it comes to Mac actually
2 Likes
If I get this right, modules don’t really exist, they are just files containing subpatch nodes. When I insert a module, what I really get is that the subpatches from the module file are inserted.
Of the cuff, I think patches need an identity (uuid) in order to identify the original patch as well as its descendants. What makes matters more complicated is that patches can be modified in all the places they are used. There is no obvious latest version and you probably don’t want to go into git-like version control. So maybe a timestamp must do to identify a version, without any notion of lineage.
Given these two bits of metadata for a patch, it would be possible to replace a specific version of a patch in a selection of files. It would also be possible to do this for all older versions or all versions.
For a patch that has become incompatible with its forebears, it might be necessary to detach it from its lineage (fresh uuid).
1 Like
Yes modules are just patch files. The problem I see with updating something is like sometimes to create a new module, I use existing modules and edit them. OR I use a module inside another module.
I guess what I’m saying is it’s a tough thing to figure out and I’m not sure what benefit it has for users? How would it replace a module with a new module but then retain the same knob/button combos?
It would make my life easier when I’m updating the library and change something like a building block and have that propogate out to everything that uses that building block, but at the same time, it seems like it could both cause some big problems and would take a while to code up (thus taking time away from other features).
I’m not poo-pooing the idea at all it would be awesome to do this I’m just not sure if it’s possible 
Oh and basically modules are little JSON packets so they do exist “by themselves” in a way, but all modules are created within Audulus and thus have to exist inside a patch file (i.e, there is no separate “module” file).
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.
2 Likes
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.
1 Like
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.
2 Likes
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
1 Like
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.
1 Like
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.
1 Like
@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.
3 Likes
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.
3 Likes
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.
1 Like
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.
1 Like