Presets possibility w/Persistent S&H
  • I am trying to do a presets recorder patch. Anything that isn't a manual field (moved by finger) will be reset on patch exit.

    I am trying to build a crude Preset recorder. While maybe Presets are in the works (to be able to record splines, etc) There can be a lot of value in creating a new type of Node that *remembers* the last value before close, and instantiate with that last value when the patch is reloaded. To make it useful, it would consist of two inputs: a trigger/gate and "in", and one output (out).

    Or it can just be a menu option of the sample and hold module, Persist [X] (off by default) that when googled, will remember the value on patch exit and instantiate with that value on patch loading.

    Just this simple change would allow all kind of simple Presets and tools to remember settings in a persistent way.

    For example, I build a "Mhhh" Module that allows one to just try random values for knobs. One can chain this Module to randomize any number of Nodes. I can also dial in manually with the same control. This seems maybe trivial (can be built within main patch) but it's not. I can plug this to any Patch and find combinations I like easily, which I could very easily store in a generic "Presets Recorder".

    To create a Preset Recorders/Player (one example, visualize 8 inputs and outputs, a mux operated by knob that allows storing 8 or 16 presets and access with a dial, recording each when a global trigger is on, just reading when off, this all goes out to "output" nodes, one per variable). Like a man in the middle, I can record/read anything and persist it over time.

    Really hope this is not to difficult (just persist the last value of sample and hold on exit) and that the possibilities are as exiting in others minds as I see them.

    Example "Mhhh" module attached...right now I can't save any cool random finding (which I intended to route to a Preset bank module I was creating, or at least persist on patch reloads). The Mhhh module just outputs a random value every time you play a note, until you select "Hold". you can dial a manual value too. See patch. It has amnesia on reload (or course).
    Clunky Strings.audulus
    1334 x 750 - 126K
  • There is a built-in preset function that you'll be able to access at some point - don't know when it will be released, but basically you can step through presets as if they were effects loops in a guitar pedal chain - as seamless as live patching. State-saving of S&H, knob positions, etc, are just a part of this schema. You wouldn't need a module to do this preset saving, it will just be another function (possibly in the menu bar, I don't know exactly what Taylor has in mind though - it's not even in alpha yet, although the code for it actually already exists within the program itself).
  • That seems awesome!

    I am sure Talor will blow our minds. In the meantime maybe (i.e. "Please" :-) option to saving S&H state now so we can store numbers.

    The good thing of being able to create modules that store, etc. is that you can use it in a very vast number of ways. To provide another example, I could store the number of times the patch was opened. The number of mins played. The distribution of keys played, etc.

  • To extend marks explanation, the undo history is currently saving every change in the patch, including branched states (meaning if you undo and do something else there is actually still a state chain for the actions of the branch of re-dos that exists but can not be accessed currently). The plan is to allow users to bookmark states and I've been mocking up some ideas for ways to implement this in the interface. I also mocked up a preset object idea that works like the max/msp preset object intended for making setting presets in sub modules. It would basically store all knob settings of the subpatch in which it is present.
  • What other software gets the devs to explain ideas? I am truly thankful for both explanations and the Undo idea is clever. If in doubt buy Audulus, you'll love it, heh.

    MichoMachines, if I get a signal from Midi event, and I want to record that into a preset (let's say I am using a chor app like ChrodBot, or SoundPrism), I can hold that notes in a non-persistent way via S&H, I can pass it to a knob too (connecting, will display Blue). It will remember the chord (which is stored now not on the knob but whatever is connected to it), and as soon as I close the patch it's gone. Same if I want to store let's say a random number. Or I am using something like the X-Y pad to find a sound I like, I can sample and hold them. But they never get stored into a knob. Let me put another case, I may have a short sequence in an external sequencer or Arp, and want to transfer it to Audulus to use presets for a synth. I could use and utility module to store 8,16, 32 note values, as I can demux quickly using Gate and CV into 8, 16, 32 S&H nodes, that connect with 8 knobs or more, and then use those as presets. But these won't get stored as they are treated as signals. So even with turning Undo into presets, no way to store anything calculated, random or incoming.

    There not a single way to store one bit arising from a signal into a knob, level except for S&H module, which will get reset every time the patch is instantiated. Only manually entered values, like a spline value or manually dialed knob will register for Undo/Redo or get stored on patch exit. If we had at least one node to remember the last bit on patch exit, we can the record chords, notes, or any number that is arrived externally or algorithmically. Let's say I want to save the first 16 Fibonacci numbers, I can rapidly make a patch to store them in a register (bank of S&H) and then use them for something else (ok, I could use a clock to recall every time, but what if I was trying to store those combined with a note value from the keyword? I can't save the calc result. I need to attach a Value node to that S&H, write the number in paper, then edit a knob and use "Set Value", enter value manually, and then I'd have a copy of the number I liked into the patch persistently. I am trying to provide examples.

    What could we do if we could remember just "1 bit" of the signals? Possibilities are endless. Imagine a grid of Triggers, I could "paint" something (say the grid is 15x15). I could send these to a Node with S&H (persistent, to later display that drawing in a grid of Lights) then change the drawing into a different one, and store into another module of S&H banks. This is another silly example, but you could end up creating a simple alphabet of lights, that could show me which note is being played (C, C#, F) thu the quantiziser if assign those modules will "led letters" to frequencies.

    Or I could use the mic, and run a sequencer to display progress (say it's 16 steps), and have the logic of the patch register the volume of my voice at each step, and record that as velocities for the notes, store them, and remember them. The the patch in play mode will play the notes with the volume I recorded with the mic.

    These are just some examples. I don't think any other modular has this.

    Anyway, awesome people. Thanks Rimini and MicroMachines. If storing one bit in S&H is not trivial (I thought I may be not that hard but actually don't have a clue if it is) or the idea isn't useful, ultimately, thanks for the answers and listening!!

  • There's a node that's coming that is a sampler node - it can be used for audio or for things like this! :)
  • I am already salivating a lot :-) ?.. I may dehidrate by the time it ships. That's for the update and all the love and goodies coming through to the app!
  • @biminiroad when is this "sampler" node going to be available? This would help me out with my similar issue here:
  • I've been bugging taylor to implement it on a daily basis, right now he has been finishing a significant revision to the main audio engine, that among other things allows use of the Z-1 unit delay node without having the entire patch go into z-1 causing heavy CPU usage. This makes a ton of very exciting things possible in the fundamental low level DSP design area that I have been making good use of in my beta tests, and we will be launching many new modules that use these techniques for high quality filters, distortions and reverbs. I was able to model things that sound like analog circuits and decent physical models. Audulus is really on the verge of becoming exponentially more exiting and capable.
  • Quite literally sounds awesome. Thanks for the update.