What's your top feature request for Audulus? :)
  • What about presets? Saving different states for a single patch and giving them names ("default", "slow", etc...)
  • These top few should be easy enough:
    Slider (essential for better module designing)
    Xy pad (fun and great for live use)
    folders (I have only had the app for a week and I already have a hard time navigating my list of patches)
    Panel area for making visual divisions in sub patches (is there something like this?)

    And a couple things that would blow the lid off this program if done right:
    table/array/buffer (like pure data, their array object allows for sampling, drawing, scoping, wavetable, spectral controls)
    Easy to use fft/ifft for spectral synthesis / effects
    I'll send you an email about another thing I want to discuss privately.
  • Also one other thing that I consider to be a bug fix:
    Right now the lock functions strangely, first I think it should have a lock closed graphic to show the state, right now it always shows open and this is confusing.

    It appears that currently it disables the ability to move around the patch, and if you are zoomed out a bit, this doesn't allow knob/button interaction. It also will zoom into a node or module if double tapped, but not zoom out or move. also allows for patch cable manipulation while locked.

    I think it would be more useful if the lock were to disable patch cable interaction, disable moving modules and nodes, and only allow knob/button interaction (from any zoom level) and movement/zooming. This way it is more like a patch edit mode when unlocked and a performance mode when locked.
  • One other little quick fix, the text seems to jiggle around as the font size changes. I assume this is from changing the font point size. Instead of changing the font point size based on zoom, use a vector based font at one size and then scale it with the zoom. That should eliminate the small changes in kerning that happen as the point sizes go odd / even.
  • @shogun5000 funny you say that cause i was just playing with Thor yesterday and had that same thought myself! I really love how you can just drop keys too - awesome for guitarists like me. Animoog has a really nice keyboard like that too. It helps when other people back me up tho so thanks for suggesting that ;)
  • +1 on the Thor type keys.
    Yes those and animoog keys probably my favourites on iOS. The Thor keys are so simple yet feel? so right.
  • @JohnInBoston - I figured out a way to normalize inputs - will post that later today :)
  • @MacroMachines I'm not adjusting the font size. Rather, the font renderer (3rd party code) is pixel-aligning the text for better anti-aliasing. It turns out there isn't a way to turn it off, as far as I can tell.
  • As MacroMachines said:

    "I think it would be more useful if the lock were to disable patch cable interaction, disable moving modules and nodes, and only allow knob/button interaction (from any zoom level) and movement/zooming. This way it is more like a patch edit mode when unlocked and a performance mode when locked."

    100% agreed.

    I also mentionned this "issue" previously and it seem to be also a problem for many users as we can read on different forum.
    We simply have to zoom in too much to be able to turn knob. Take example on Zmors modular, you have direct access on many modules within the ipad screen.
  • I agree with both @MacroMachines and @shogun5000 about how having lock toggle between a player mode and edit mode with respect to controlling trigger and knob control elements in player mode at any zoom level and having the cables locked. This would really allow you to play Audulus without worrying about accidentally dislodging cables in the process.

    It would also be very nice to have a way to record the status of control elements in patches (knobs and triggers) so you can have preset functionality. With presets you'd be able to replicate desired sound chains for integration into your music work flow. When Audulus has MIDI out capabilities, this could be as simple as pressing a preset trigger which then sends MIDI to the patch controllers to set the state of the controls in the patch. These MIDI control elements could also be used to control other MIDI apps and MIDI hardware.
  • @Paulinko - the preset functionality you're talking about is already in Audulus - it just hasn't been brought out for the user yet. You'll really love the way Taylor set up this new preset thing, it's very useful.
  • @biminiroad that sounds great, I think Audulus is well down the road to becoming even more functional and playable.
  • I went through all these feature requests and condensed them into a spreadsheet, separating them into things that @Taylor needs to build into Audulus and things that users should build themselves using nodes and modules - hope this clarifies what you can and can't do within Audulus. Most requests that go "outside" of Audulus (MIDI Out, or Expert Sleepers functionality, for example) are things that only Taylor can do. Take a look at the list, however, and you'll see that almost half of what has been requested is something you can already build yourself with the ingredients you've been given :)

    This is not an official Audulus document - opinions contained within are my own. If you want me to go deeper in explaining something, let me know!

    https://docs.google.com/spreadsheets/d/1-Djs3ufQyM1GaS5g5F-EB8r5nhZkuOSQ1urTNcirtgw/edit?usp=sharing
  • will proper midi in be implemented with midi out? i am waiting to build any awesome ipad midi controller templates until we can specify port/channel and use multiple controllers.
  • @mellonhead - this is already in beta :)
  • @biminiroad, that looks like a pretty solid list! With regard to Normalized connections, you teased above (Jan 9) that you figured out an existing way to do it that you would post later in the day, but I must have missed it. Do you have a pointer to an example?

    J in B
  • Screen Shot 2016-01-20 at 7.20.08 PM.png
    1920 x 1080 - 796K
  • +1 plugin parameter control
  • An option to oversample everything, so that you could render your sequenced Audulus parts at higher quality when bouncing if you don't have a powerful enough PC.
  • Hello everyone!

    I just got Audulus last night and got lost with one of its presets for several hours (Cora)! :-)

    One more vote for MIDI in/out and everything in between. Some time ago there was a Windows program called Building Blocks by Aureality. The site is down now and the program has not been updated for more than 10 years. It would do for MIDI notes what Audulus is doing for audio: sequencers, math expressions, clocks, probabilistic processing, map to scales, FIFO/FILO note lists, multiple conditional modules, and too many other modules that I don't remember right now.

    Probably Max or Plogue (?) can do this MIDI manipulation, but having both audio and MIDI flexibility in Audulus would be a dream!

    Thanks for a great app!
  • +1000 @kozmyk!

    God I wish I could find Building Blocks again... I need it now.

    If we set up a Kickstarter for midi in/out capabilities would that help move things up in the roadmap? #kindanotkidding

  • @DrumMonkey

    I still have it and run it on a relatively recent PC with Windows 10 and the LoopBe1 virtual MIDI driver... and it works!

    The pain in the a** with it is that the UI is so difficult to work with, and I think if too many clocks are active, the tempo and timers on the top control tool bar are starting to go bonkers. Also, it was developed several years ago for much weaker Intel CPUs so the full program eventually hits a brick wall after a few modules are active.

    I'm surprised no one has picked up on this idea -- manipulate MIDI notes. Max and Plogue can probably do it, but Building Blocks was a focused environment for MIDI mangling.

    Hopefully we'll see something similar again.
  • midi is just numbers, so yeah anything you can do with dsp can be done to midi in the max environment. there are also a ton of patches for generative composition. i think the issue with midi here is not, "does it work at all," but, "does it differentiate between my pad controller, my keyboard, and my wiimote?"
  • i have been told the features we seek are in the beta, so, yay!
  • Also, what people want here, really, is MIDI I/O - the midi doesn't have to stay "MIDI" while within Audulus - it just needs to be able to be converted back into MIDI on the way out. I have plans for lots of MIDI effects, including a neat one that y'all might like called the Pachinko Router.

    What you need to do here is think about how MIDI gets converted into different numbers (Hz and Gate signal) and then how you can do interesting things to those signals separately, then recombine them on the way out again into MIDI out, which Taylor has yet to but will soon implement.
  • I can hardly wait for the MIDI I/O. It would be very nice on iOS to specify the channels you're sending and receiving MIDI from.
  • I am personally in desperate need of folders for patches.
    image.png
    2732 x 2048 - 308K
  • What he said:

    "MacroMachinesMacroMachines January 4
    Also one other thing that I consider to be a bug fix:
    Right now the lock functions strangely, first I think it should have a lock closed graphic to show the state, right now it always shows open and this is confusing.

    It appears that currently it disables the ability to move around the patch, and if you are zoomed out a bit, this doesn't allow knob/button interaction. It also will zoom into a node or module if double tapped, but not zoom out or move. also allows for patch cable manipulation while locked.

    I think it would be more useful if the lock were to disable patch cable interaction, disable moving modules and nodes, and only allow knob/button interaction (from any zoom level) and movement/zooming. This way it is more like a patch edit mode when unlocked and a performance mode when locked."
  • On iOS the lock icon now works correctly after the latest update.
  • It would be nice that when setting value the default would not be 0.0 but it would be either 0 or the field would be empty and if nothing would be written, the default would be zero. I am tired a bit because of using the backspace all the time. :-)
  • No, in my opinion it doesn't because we still can't pan or zoom while locked. I want a mode where the lock only locks the relative position of nodes and modules and the connections. I want to pan and zoom around my creation to tweak knobs but not risk accidentally breaking my patch during a performance.

    I'm running the iOS 3.1 version released 3/8/16.

    "Paulinko March 12
    On iOS the lock icon now works correctly after the latest update."
  • PS: I'm having such a blast with this app. I'm seriously thinking of upgrading my iPad Mini to an iPad Pro for this app alone. Maybe when I retire I can afford going down the Eurorack rabbit hole. But until then, this is a much more economical platform, but also in so many ways a much more creative and expressive one.
  • @WeirdoLoudypants, glad you're enjoying Audulus! How about being able to individually lock nodes via the context menu? (like locking shapes in a drawing program)
  • @Taylor and @WeirdoLoudypants
    I'm with Weirdo on this one. A mode where positions and connections are locked but pan/zoom and knob/button are accessible would make a good performance mode. Especially if knobs and buttons were functional at lower zoom levels.
  • @Taylor, the way that the lock function currently works I just cannot find useful, especially when the auto-zoom still works, but you can't zoom out. What @JDRaoul said above gets to the heart of the issue.

    As for individually locking nodes and sub-patches, that could get a little tedious especially for large patches. That's not to say that I don't think it would work at all. It would be interesting to be able to lock a node or sub-patch such that you could still tweak knobs and the cables would be locked to it, but maybe then you could change the connection to another node that is not locked. If individual locking could be applied when you lasso multiple nodes and sub-patches, and it applied recursively into sub-patches, that would be useful. But only if you could still zoom and pan around.

    Still, the crux of this is the locking of connections and while keeping the ability to zoom. The way locking works now just does not seem useful to me at all.
  • @Taylor I'm with @WeirdoLoudypants and @JDRaoul on having a playable, zoomable lock mode where you can still use knobs and buttons.
  • The goal of lock mode is to enable multitouch interaction (though this isn't yet implemented), so we have to disable pinch-zoom for that. We'll have to think about how to express the two levels of locking.
  • Oh... When you thrown in multi-touch I see the problem. Maybe a separate "performance mode" where the panning and zooming is done through a virtual game pad type control like the iOS version of Minecraft. Just a thought.

    One thing that should be done for sure is to disable the auto-zoom in the current lock mode. That is super frustrating since you can't back out. It would be nice if the buttons and knobs worked in the current lock mode even when you're zoomed out.
  • Hi. + 1 for CV connectivity to hardware modulars via Expert Sleepers modules.
    Really loving Audulus. Thanks.
  • @Taylor I understand the problem. I hope we can find a solution. A mode that allows navigation and easy access to controls without endangering connections and module placement.
    I guess the workaround is to make performance modules which expose relevant controls without external connections.
  • Another solution might be the ability to expose controls all the way up to the top patch level, even if they are in sub-patches, or sub-patches of sub-patches. Then you could design a patch, dump everything into a sub-patch, and then expose all the controls you want for performance, regardless of how deep they are embedded in the patch. Still the auto-zoom function needs to be disabled in the current locked mode to make this fool-proof.


    "JDRaoul 8:55AM
    @Taylor I understand the problem. I hope we can find a solution. A mode that allows navigation and easy access to controls without endangering connections and module placement.
    I guess the workaround is to make performance modules which expose relevant controls without external connections."
  • Module SDK. I.e. an SDK (in e.g. C++ or some higher level language) that allows user-led development of Audulus modules.

    An "extern" module could be related to this. I.e. a module that runs "external code".
  • @mviljamaa An SDK is an excellent idea. There are some drawbacks though. We can't load externs on iOS (loading code at runtime is forbidden for security reasons), so patches made with desktop versions wouldn't be portable. Also, having a SDK constrains how I implement the audio engine and creates another requirement for backwards compatibility. I'd like to see how far we can go with creating fundamental nodes that people can do a lot with. Expect some cool stuff in the future :)
  • I would like to be able to pan by pressing the mouse wheel, rather that by holding the alt key (windows).
  • @Taylor

    Can't you just allow the compilation of the external modules before moving onto iOS? That they would be editable only in the desktop version, but would have to be compiled in order to be opened in the iOS version?
  • I need a real XY pad, it doesn't seem like this is a thing yet. I would like to replace my kaosillator with something like audulus on an iPad where I can program my own synths. Is a real XY pad on the list of soon to come devices? Thanks
  • How about support for android? I am considering buying the new Samsung Galaxy Note 6 when it comes out, and i'd love nothing more than to use it for Audulus.
  • @mviljamaa I don't understand what you mean. External code can't be loaded on iOS so it would be a desktop-only feature. That would break patch portability, which has been a central goal.