I feel like I have benefited quite a bit over the last month from some of the heads around here and I am wondering what the best way to give back to the community might be. Does anyone have any ideas?
Just being an active participant in the forum and doing what you can to popularize Audulus is thanks enough for me. The more people who invest in Audulus, the more resources they will have available to improve the product. Being an independent software developer is a very difficult proposition, particularly in the iOS market. Anything we can do to help the fine people at Audulus LLC will ultimately benefit us all. Be sure to give Audulus a five star review on whatever App Store is appropriate, and update it when a new version is released. The reviews really make a difference. We’re glad to have you with us!
Sharing is caring as they say. Post some of the patches you have been making
Yeah the two best things users can do is make stuff and share it here, and tell others about Audulus. You can do that online or in person at a synth meetup!
Probably some superfluous connections, it’s heavy on the cpu and not deep into nodes. It would be cool to some time have a tutorial called “why your patch sucks,” which could include key tips on how to achieve the same results without maxing your processor. I find I get limited quickly by my chip. Especially because the best case scenario would be to have this sort of thing running on a track while playing bass, guitar and drums in the iPad. I’m up to 53% here.
I forget, what iPad do you have? I actually quite like the patch, it has a harry parch vibe going on. It’s running about 17% on my mac.
iPad Mini 4. I would have bought a pro but I wanted something small. Hopefully they will be smart enough to make a “Mini Pro” in the future.
Yeah a mini pro would be fantastic. I like the mini 4’s display, but I agree it feels cramped in the cpu department.
Imagine a the speed of an iPad pro, but with less GPU overhead!
I find that too many designers want to make things flashy. Myself, I want things that draw as little attention as possible. When I start pulling out all of my gear, I really don’t want to be seen. This is one of the main reasons I wanted a mini – pulling out a giant iPad in the wrong neighbourhood is a bad idea.
A good place to start for analyzing your patch is the little clock icon that shows what percentage each module is using. Then you can focus on the things that are the biggest hogs. The quantizer is kind of CPU heavy. If you’re not using one of the scales that are not well tempered (last 5), the uQuant is much more efficient.
The only thing I would change about this patch is to use an Audio to Modulation converter when sending Audio to your filter CV attenuator.
You can also use a clamp(Audio,0,1) expression to rectify the signal if you only want to include the positive portion of the wave.
In the future, Audulus knobs will be clamped between 0 and 1 so this won’t be an issue anymore.
It’s not a problem per se in your patch, but in some situations, like with Q and ADSR periods, negative values make things go a little wonky.
I noticed the clamped knob is already in the macOS version, but I have avoided using it since it’s not in the iOS version yet.
You can and should go ahead and use the clamped knob - it’s not available to select in iOS but you can still open patches with it.
Is it really going to not have labels? That makes tracking what knob is which much more difficult.
The idea is to limit the number of hidden menus and options in Audulus to a much more plain WYSIWYG.
As most people don’t even use knob labeling for its intended purpose, it’s better that we find a more efficient way of labeling.
One idea we floated in the git feature request is to have a split screen mode in Audulus where you can see inside of and outside of a patch at the same time. When you tap on a knob, it would highlight on the UI. This is a more elegant solution than naming/unnaming something.
When I tried that originally the clamped knob didn’t show up. It seems to be working now.
Well, for now, I am sticking with the normal knob because labeling is important to me. I agree that menu trees need to be pruned, but until the visual highlighting is integrated I would revert to making errors in patch design. Labeling is more or less foolproof the way I use it.
Yeah the old knobs will still work in the future, they just won’t be able to be created. In the module library, though, I’ll be replacing all the knobs with clamped knobs (sigh - that will take a while, lol).
Please keep labeling for sure then. I think the ability to keep things straight is intrinsically different from the “set min/set max” functions of the current knob.
We’re definitely getting rid of labeling, as well as Min/Max.
If labeling is only used to figure out which knob is which and not to label the knob, then it’s not doing its job and we should figure out a better way to do the same thing but with less effort.
You probably already know this, but there are two things you can do right now that would help you transition to the clamped knob:
Set knobs to visually distinguishable levels - so if you have 4 knobs, one is turned all the way down, the next is 1/3 way up, next is 2/3rd up, and the final one is all the way up. It’s as good as labeling them 1, 2, 3, 4.
Use default knobs - create a default set of knobs where they’re laid out in a row or something away from the 0,0 origin point and paste those into your patch and use which ones you need. You’ll be able to know which are which from their initial layout.