Well, I wouldn’t mind if the Audulus AU3 had a highly pixilated icon mode if it meant things running more smoothly.
1 Like
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.
2 Likes
AdulusBMvect.audulus (240.6 KB)
Audulus SVG Comparisons
| Original | Bad | Okay | Good |
|---|---|---|---|
 |
 |
 |
 |
| 5 kb png | 187 kb svg | 47 kb svg | 3 kb svg |
| scale 50x50 px | Original to SVG conversionn from original |
Original to SVG conversion from good svg |
SVG gradient won’t render in Audulus 3 due to basic SVG support |
| icon colors normal |
icon colors normal |
icon colors reversed |
icon colors reversed |
3 Likes
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
| Feature | Function | Comment |
|---|---|---|
| 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
| Issue | Why |
|---|---|
| Edit | It’s preset based so no changes |
| Objects Move | Only controls and displays move |
| Subpatch | Will not be opening subpatches |
1 Like
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.
2 Likes
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.
1 Like
I will invest some time into doing mockups and videos to describe what’s in the outline here.
Why GUI Screen Control?
| Concept | Explanation |
|---|---|
| Flexibility | Add the ability to seperate programming structure from playing functionality. |
| Optimize Screen | Add the ability to change objects on the screen using knobs and triggers or through logic programed into Audulus. |
| Enrich Connections | Adds the ability to be interactive, do tutorials, display help, switch controls . . . |
| Player Orientation | Create GUIs which appear and function like other music apps so no specialized Audulus knowledge is required to use patches designed for those users. |
| Efficiency | Combine with GUI Play Mode where only the aspects that are part of the GUI are accessable means all of the other display/editing resources in the app will not be needed. |
| Patch Creation | Users can setup or use existing patch GUIs to facilitate patch construction. |
GUI Screen Control
| Feature | Function | Comment |
|---|---|---|
| Seperate Controls | Play versus Program | resolve mode conflicts |
| In Window | objects display | changes to objects within window |
| Swap Window | swap out all objects | trigger and/or knob initiates |
Usage Examples
| Example | Details |
|---|---|
| Display | user can change displays |
| Settings | display controls to set patch parameters |
| Filter | change filters and their settings |
| Sequencer | setup and/or control sequencer |
| Scale | change scale |
| Tutorials | create tutorials on how to use a patch |
| Program Tool | jump to specific locations in the patch |
GUI Setup
| Example | Details |
|---|---|
| GUI Module | a set of controls in a subpatch |
| GUI Controls | a module of controls |
| GUI Displays | a module of displays |
| GUI Sequencer | a patch with the logical structure for a set of GUIs |
2 Likes
I’m not sure why you can’t implement all of this in the current iteration of Audulus?
Like this:
Create GUIs which appear and function like other music apps so no specialized Audulus knowledge is required to use patches designed for those users.
Why can’t we do that already?
Things move, cables disconnect, editing features pop up during the process of playing, we have to jam things into one window or scroll through a long complicated patch, or restructure, I could be here all day talking about these differences.
It sounds like we just need a better lock mode, no?
1 Like
If this needs to be a separate app that uses patches imported from the regular Audulus, that would be fine and I’d be happy to pay for it.
1 Like
No, clearly I’ll have to do some mockups and videos as you have no idea what I’m trying to communicate.
2 Likes
I think I do know what you’re trying to communicate, I’m just not sure why a better lock mode doesn’t solve most of the problems you have with the way the AU works. The lock mode could prevent you from disconnecting cables, it could suppress edit functions from popping up, from moving things, etc.
I know you don’t know what I’m trying to describe and it’s very presumptuous of you to claim you do on the basis of a very abstract outline which has not been fleshed out. Please exercise some patience and let me do my videos and mockups. It may end up being nothing Audulus LLC. would be interested in doing; however, at least I would be satisfied that I’ve described my ideas sufficiently.
You have been very quick to knock down user suggestions in this thread and I do not appreciate it as it tends to inhibit open discussion in my opinion.
1 Like
It sounds like you’re suggesting making a version of the plugin that loads an Audulus patch with a UI that a user can create themselves. This would be a raster UI that doesn’t need to do all the fancy vector infinite canvas stuff that Audulus does right now and thus save CPU and be more familiar to people. Underlying it would be Audulus’ audio engine and a patch you make in Audulus.
Is that not what you’re asking for?
This thread is a discussion and I’m discussing these requests with you and others. If what you’re asking for is not a clear no-brainer amazing idea that’s also simple to implement, then you and others should expect to be able to support why your idea is so great. In the process of this back and forth we usually come to something better than the original idea.
You were proposing that your solution would solve problems that could be more easily solved another way, and my point was, if that’s most of the reason for doing this alternate GUI thing that would take a long time to program and take away time from other feature development, what makes it that much better than adjusting how the lock function works that would make it worth the time to do it?
If in the end I’m wrong about the way I interpreted what you’re saying, please don’t think it’s presumptuous that I could read what you’ve written and try to guess at what you mean.
The lock mode is almost no different from regular mode, so any change is welcome in that department.
1 Like
You’ll have to excuse @biminiroad he tends to be the convergent voice in the discussion rather than the divergent one. Keep in mind that it is literally his job to politely tell people what is and isn’t likely. I for one would like to see what you have in mind, and think there is value in seeing what might possibly be a new direction Audulus could go in, if not now then in the future.
1 Like
Yes! I don’t want to shoot down good ideas but defense of good ideas leads to good features.
1 Like