Forum

The more possibilities people have with Workbench the bigger the probability will be that they want additional agents to reach their goals. Starting a thread to collect some ideas what would be nice (perhaps some things could make it on the open source developer proposal list?)

low level agents that allow to build easy logic components without having to go down to programming level:
* a selector: one of several inputs is chosen based on a "chooser input" (a value input that determines the input that is routed to the output)
* clock: measures the time between two input signals (e.g. key presses)
* timer: send a trigger after a specified period of time
* variable: just outputs a specified value (can also be used as "sample and hold")
* comparator: compares values coming from two inputs and outputs e.g. -1 0 or 1 depending on the values being equal/left bigger/ left smaller
* key stream and midi stream creators/extractors (build key or midi streams out of individual integer/float values)
* what would be cool: low level components that are put into a special rig which are not agent themselves but compiled to sample-rate optimized machine code on the fly, so you don't have the call overhead and can essentially build smaller realtime DSP schematics directly in Workbench)

high level agents:
* fingerer agent for playing with "mode keys" to add accidentals or reaching a bigger playing range on Pico. E.g. transpose by a semitone when pressing a mode key or having three mode keys that encode which octave is played (as far as I understood this is already in the pipeline)
* coding agent: an agent with a Workbench gui that allows to use Python and a compiled language (e.g. TransLucid?) to write small agents directly in Workbench (for Python it should be a "simple agent" approach where you essentially only define the process method).
* an additive synth component that can resynthize existing sounds and morph between them in several dimensions (or even better: real time resynthesis and morphing between several inputs, so you could morph between a synth sound from the modular components, a sample instrument and a voice from the microphone - whatever)
* a collection of (or one monolithic, configurable) "physical modelling" agent(s) that can be used to build possible or impossible instruments (e.g. strings, resonators, bow, pluck, blow attractor etc. but perhaps also crazy things like tree-with-leaves that can be blown or shaked). Optimally there is a dedicated "3D editor" in workbench that allows to graphically build instruments - take a box, span strings accross it, put a membrane on it, make a whole so sound can exit, put strings on a stick to build a bow, define axis on a "hand" that plays the bow, define fingers/hammers that touch/pluck/strike the stings etc. Ok, in full scope this might be more challenging and time consuming to implement than the whole EigenD package together by itself - but it would be cool! (Perhaps as a first step one could use e.g. just launch Blender as an external application to build the physical instruments - Blender has a Python interface, so an exporter/agent controller could be written) (Perhaps it would be worthwhile to look into programming the new multi purpose GPUs for the physical simulation.)
* "section agent": instantiates another selectable agent n times and provides the "instance number" to the contained agent (if it supports this property), so the contained agent can vary the sound slightly based on the instance number. The outputs of all instances are summed up. That way you can build sections of instruments (e.g. for building synth orchestras)
* an audio unit agent that can hold several instances of the same plugin, dispatching midi events based on channels to the instances and controlling all instances with the same gui (so you can have per key expression for plugins that do not support a multi mono mode without having to manually synchronize changes between the instances). (Geert meant this is already on his agenda.)
* a filter agent that can filter keys, midi events, values etc. based on intervals, type etc.

to be continued :)

This is a great discussion. We have a big (giant might be a better word, its got lots of your ideas from the last 2 years on it) feature request list on our bug tracker which we'll try and find a way of sharing at some point. We were actually talking about a short list of Agents that it would be cool for people to have go at during and after the Devcon yesterday, and we'll post our suggestions here early next week. They share many similarities with ideas already posted. The biggest challenge is really gauging the difficulty so that the challenges are tractable for everyone. Sometimes things that look simple turn out to be really hard when they have to be real time and happen in under 5ms.


Comments on suggestions so far (long post):

Yes 'Fingerer' is already an Agent, it just doesn't work yet. I'm writing that so it's going slowly. It's a bigger headache than you might think, like everything else in music programming. I was doing fine right up to the point I sat down with Ian Ritchie to test it and he broke it pretty thoroughly over a half hour period, sending me back to the drawing board. I started back on it this morning in a nice coincidence.

On the embedded language front, we've been mulling over a LUA Agent as it looks like it might be possible. Python is not good for the performance data for a couple of reasons, the GIL being one. The 'low level compiled components' thing is a nice idea but I suspect really, really hard to get right and quite possibly rather user hostile. Don't let me deter you from trying though.

On the physical modelling front, I'm really keen on physics model oscillators if anyone wants to have a go at that. We have a good Helmholtz (bowed string) oscillator already, and a great single reed linear tube model (used in the clarinet). There's a decent convolution Agent as well. The really big one missing is a plucked string, although once you start to think about this stuff the possibilities are endless. There's a nice existing framework (cfilter) to take care of a lot of the boring event stuff for you when writing this kind of Agent as well, so although it's hard from the sonic and physics point of view, the coding is much more straightforward.

On the timeline front, the existing Scheduler already does quite a bit of stuff and if it had a little interface love then it could be very cool. I don't think there's really a need to reinvent that - that kind of code is also really hard to get right as it's chock full of corner cases and fencepost errors usually abound. There is the possibility of making an arrange window type interface for it, which would be very cool, although this is quite some project as it has to interact with a number of things including the recorders. If someone wants to play with this stuff, we could get together for a workshop to flesh something out at the conference. We also want to change the way recording works soon, possibly centralising the recorders into one agent in a smart way - this would make this problem much easier to manage.

I love the idea of a 'Section Agent' even if it does sound like a recipe for killing ones computer dead in a jiffy. I'm not sure how practical it is from that point of view along with the problem of how it interacts well with the GUI tools. The 'multiple parallel AU hosting' is on our feature queue already.

The idea of a collection of really light logic and signal flow Agents is one thats coming up often, and we're keen on that too. Gate functions, data transformations etc are all a good idea. A 1/2 hr discussion could probably flesh out half a dozen easy to write, dead useful little Agents. I'm keen on these as projects for people, as it's small enough to be manageable and really useful at the same time.

I'll throw one idea in that I really want - an arpeggiator Agent. Variety of possibilities for this, be a great little project for someone. There could be a series of these Agents, in different styles.

And, right off the feature queue, a chord generator. This is one of those 'harder than it sounds' ones. I'll leave figuring out why as an exercise for the reader!

And a perenial fave - adding accidental support to the scaler via modifiers - we've got the 'what to do' bit of this figured out, it's the actually doing it that is next and would also make a nice introductory project, especially as Jim has now made scale intervals fully floating point. You would be a popular man if you nailed this one I think.

And finally (sorry, long post) -one thing to bear in mind in all these suggestions is that when you're evaluating an idea for how difficult it might be you have to bear in mind that EigenD also represents a slightly odd moral landscape for the software developer. The main issue revolves around GUI's, in that there is one golden, never break, rule which is that there should be nothing that one *ever* might want to do in performance that should require one to use a GUI. It's considered OK if it's easier with a GUI (like Workbench for plumbing for example, or Stage to turn a volume down) but it should never, ever, be mandatory. This makes life difficult in quite a few cases and means some styles of application are basically either not possible or much harder (I'm thinking about the arrange window style things), but its also one of the very cool things about EigenD. You can use it without a computer screen.


John

Heya Antonio,
I had a few of those in my notes too! To which I'll add:
- Quantiser - (to add to the noise and S&H agents)
- Sync between oscillators

D