rsdio's Recent Posts
We want to explore every vector of expression possible for the Soundplane.
I have done a lot of work with MIDI, including MIDI guitar, and I assure you that we will support MIDI to the fullest extent possible. I am not drinking the OSC coolaid yet, so there is no bias. MIDI will not be ignored here.
That said, analog CV can do things that simply are not possible with MIDI, and OSC will certainly have its own advantages and disadvantages, too. In fact, if you can provide a link to details about Eigenlabs' OSC problems, then I would like to include that in my research. Please keep the discussion open!
Here is some food for thought about how the link between controller and sound generation device can audibly affect the musician's expressive options:
I, too, wish that the Soundplane A were ready to sell to everyone interested. Even though it's my job to design and develop the electronics and firmware, I'm also an eager customer who just wants to play! We've been talking about taking photos of our work, but sometimes it's hard to justify stopping the progress long enough to grab the camera, compose some shots, upload the photos, and make comments. A Press Release, especially with photos, is nothing to be taken lightly.
We hear you, though, and hopefully we can find some clever ways to give you all some more concrete reassurances without slowing down too much.
I don't think that the MacBook Pro supports 8-channel ADAT on its TOSLINK I/O. The ADA8000 probably doesn't support standard stereo digital audio over TOSLINK, either. In other words, they don't speak the same language.
Give it a try if you have the opportunity, but I have a hunch it won't work without writing some kind of serious driver for the MBP. I would not recommend buying the ADA8000 if you want it to do this, at least not without testing first.
There are many audio interfaces which have ADAT, but most either have 8 analog I/O or cost as much as 8 analog I/O.
I agree: This is a great idea.
But you seem to have dreamed up a really complex method for random patch generation that might take a while to fully realize. In the mean time, you might consider a pure random approach. Your GUI would just have a button and text output for the patch. Each value would have the full range (whatever that may be). Once you get this working (assuming you don't already have something basic like this), then you can start getting fancy.
As for the ultimate version, you might want to think about having classes of parameters, so that you don't have to treat every parameter completely separately. Each class would have a specific range and a particular kind of GUI to set the randomness. Once you have these basic building blocks, you can put together a GUI that allows fine control over the randomness of each parameter.
However, I tend to believe that 90% of the utility of random patches can be served by purely random values. Not that there isn't a great deal of utility to having a finely-tuned engine for creating controlled random values, but sometimes it's easier to click a button several times to skip past dud patches until something useful comes along. Then you can use the Aalto GUI to fine-tune the patch from the purely random starting point. In other words, why spend a lot of time on generating a controlled random patch when you can quickly jump through lots of wildly random patches until something sounds interesting. I tend to learn more from wildly random patches anyway, because they incorporate elements that I would not have thought of if I were trying to control the process in detail.
Another idea would be to put intelligence into your random generator. If a particular 'amount' knob has a random value, but no modulator is assigned to the input for that knob, then it's kinda pointless. So, perhaps some understanding in the random number generator about the interaction between modulation cables and modulation amounts might help create a higher percentage of useful patches. I think this might end up tying in with the classes of objects that I mentioned above.
Keep us posted on your progress, and feel free to continue with questions and ideas.
On the question of MIDI mapping, sometimes it's best to have a fixed map so you have one less thing that can go wrong.
Most hardware controllers can be mapped internally. Most AudioUnit hosts offer MIDI mapping, too. Between the two of those, you should always have mapping options.
If Aalto were to add mapping, then there'd potentially be three different places to check. If your maps don't work, it's best to have fewer places to double-check. When you plug into a new system, it usually helps if there aren't multiple layers of remapping.
Of course, all of the above is speaking in terms of mapping. Another question is whether Aalto would open the MIDI input device directly, without leaving the host to make that connection between a device and the AudioUnit parameters. It's probably best to keep things simple and avoid this complexity. Direct MIDI access might not work the same in every host.
In any case, I have no say in what features get added, but I did want to throw in my two cents concerning the pros and cons of these MIDI features.
Thanks for mentioning Arc. It looks like a great idea. I am always a fan of human interface controls which offer a fine resolution of interaction. Arc seems to not only have fine control, but the LED ring is also much higher resolution than anything else I have seen.
Is this an equal-tempered piece? Sounds like it might have an alternate tuning...
Yes, I think the most obvious solution is the optimized release of Aalto, which seems to be imminent based upon the information elsewhere on this site.
Meanwhile, "Bypass" is a concept which all DAW software implements, not the name of an effect.
In Logic, when you insert an instrument into a track and open the UI window, there is a Bypass button. This is true whether it's one of the proprietary plugins that comes with Logic, or a third-party instrument like Aalto. Bypass is available for all effects and instruments. A quick shortcut for this, without even opening the UI, is to Alt-click the instrument in the I/O insert on your track.
In Live, the concept is abbreviated to the simple universal I-O icon for a power button. When you're not using an effect or instrument, you bypass or "turn it off" to save CPU power.
I'll stop here with the specific examples, but I think you'll find that all DAW software has the same concept implemented in one way or another.
I believe that Logic and many CoreAudio hosts can only use one CPU thread for audio. GUI and other parts of the program can use all CPUs because there are no repercussions to breaking those threads apart. Logic Node is about the only way to take advantage of more than one processor. I am not 100% certain of this, but it seems to be what I have read.
I think that using the effect Bypass should be a clear way to reduce CPU usage. I have not personally tested how Aalto currently handles Bypass, but hopefully that could be implemented if it isn't already. Bypass should allow you to leave Aalto inserted in your host with a patch loaded, but taking no CPU.
Using MIDI Notes to start an oscillator can be a problem, since a long release means that the oscillators should continue to run well after the MIDI Note Off message.
There's also the consideration that an analog modular synth still runs the oscillator even when the Gate is off, allowing organic phase variations between each note - stopping the oscillator could make it less analog.
CV: Control Voltage
SRC: Sample Rate Conversion
... but it sounds like you have plenty of more interesting things to work on first. Have fun!
Wow! Very cool, Daniel.
I cannot tell whether 384 ksps @ 10-bit is a control voltage or an audio signal, but I have a few ideas. The first video looked more like a Moog or Buchla ribbon controller, but the second video looks more like a 2-string guitar with an audio interface at a higher sample rate but lower quantization.
If the controller outputs audio signals, then you certainly will need to do some processing in Max/MSP or other software to turn this into a control signal. Then you can send MIDI to Aalto. You don't need any changes to Aalto to support this because there are many ways to get MIDI from one application to another, and with the right host application you might even have Max/MSP and Aalto in the same program (Ableton Max for Live).
There is no pitch-to-CV in Aalto (because it isn't needed), and thus you might want to supply that sort of conversion in your own software. I cannot tell from your demos whether your controller system is designed to react to frequency or voltage.
If your controller were a ribbon controller outputting a control voltage, then you could still use the above approach, but it would be much simpler and easier. The idea just occurred to me that Aalto could accept audio signals as control voltage inputs. That might be a good thing to request as a potential future upgrade. The sample rate for the CV would be limited to what the host can provide, and that would be a lot of resource bandwidth to devote to CV, but you could use SRC. However, I get the impression now that you're not producing CV.
In any case, your experiments look very interesting. I am sure there are probably a few different ways to link your controller with Aalto. For now, I suggest starting with MIDI as the common link and see how far you can get. MIDI has 14-bit resolution, just not at the bandwidth you're creating, but that should still provide a workable connection.
What sorts of audio plugin hosts are 64-bit on Windows?
How many independent controls do you have with that device? It looks like one or two. What resolution? 10-bit? 12-bit? 14-bit? Depending upon the details, you should be able to use MIDI to connect to Aalto with any DAW that is an AudioUnit host, or possibly even OSC (Ableton Live?).
ESSW would be a good option, but requires a plugin host and DC-capable audio interface. That's a lot of extra links in the chain. The Soundplane will surely be able to generate MIDI and/or OSC, and so it can be patched in without approaching Expert Sleepers for special consideration. There's also the option of having the Soundplane CV go directly to a compatible audio output without using ESSW, thus avoiding the plugin and host where not otherwise needed.
Don't forget existing MIDI-to-CV interfaces out there. If you're considering a DAW plugin and DC-output audio interface, then you can equally consider one of the 12-bit or 16-bit MIDI-to-CV interfaces. I'm not quite sure how to take advantage of the full 16-bit converters in these, but the Soundplane software will attempt to take full advantage of whatever is available, at least that would be the goal.
As for the limitations of MIDI, that's mostly a myth. The most accurate control surfaces for mixing have 10-bit resolution on the faders. I am not aware of any control surface which exceeds 12-bit resolution. MIDI supports 14-bit resolution on each of 512 controls (more if you have multiple MIDI cables), which far exceeds any available control surface. Also, OSC tends to hard-code the control surface name in the message, making it difficult to plug in an arbitrary control surface to an arbitrary program, unless you use monome emulation, which is a bit limited since the monome does not support pressure. OSC just isn't plug-and-play like MIDI, and MIDI isn't really as limited as the 'net likes to think.
In any case, the Soundplane should eventually support as many standards as are useful and compatible. The priority will be workable solutions for CV output.
Maybe Randy and others who are getting 30% or lower CPU could list the exact version of Logic being used and the various pertinent settings like buffer size. I rarely do real-time, so I work with 1024 frames for the buffer and pre-sequenced MIDI is fine. This is the safest setting for crackle-free audio. Folks who want interactive playback from live MIDI sources might be trying to crank down on the buffer size too much, and it might be helpful to document the limits of what works (even though it will be different for each hardware and setup).
@dsk if you want to minimize the amount of work that you'll have to do for the controller itself, then you might consider the Livid Instruments Builder Brain.
It's certainly not the cheapest USB-MIDI DIY kit, but it has 64 analog inputs, so you'd be able to set up as many as 32 joysticks without writing a line of code. You'd still need to provide a case, joystick, and mechanical skills to put it all together, but the rest is basically done for you.
The Brain is something that I designed for Livid as a base for all of their products, and it's completely different from the Soundplane.
I probably cannot offer all of the help that you need, but I do have some comments.
For the joysticks or any pots, 100k or 50k will be just fine. Actually, larger values are better because they draw less current, and with today's low-power devices this translates into longer battery life. If you have troubles with your existing A/D inputs, then you might want to add a fast op-amp voltage-follower circuit between the wiper of the pot and the A/D input. This will allow the A/D to track the input without causing the voltage to droop during the conversion. Some A/D chips already have this built in, but others leave that to the circuit designer.
Trackpads may work something like a pot or joystick, but you will need specifications and wiring diagrams from the manufacturer to be sure. That, or you'll need to do some investigation on your own!
Good luck with your projects, and hopefully you can find one of the many online circuit communities where perhaps people are already doing the same. I remember seeing some interesting hand-made controllers over on the Livid Instruments Forum, but I don't know whether any training is provided by those folks.
In any case, be safe!
In case anyone is interested in the numbers, the first prototype is running at 125 kHz, up from the original plan of 60 kHz. This represents 80 Mb/s of data flowing around internally. It's not that you can actually hear the ultrasonic control signals, but these higher frequencies will allow even faster response. The second prototype is also designed to run at this higher rate. All such numbers, of course, are subject to change between prototypes and final production, but I figured a few people might be following the design updates.
Since the Soundplane A isn't for sale today, perhaps some of you would be interested in reading "Analog Days: The Invention and Impact of the Moog Synthesizer." I enjoyed it, and found it quite inspirational. Here's to continued boundary shifting!
I would not say that the Soundplane A is very similar in function to a Continuum. The Continuum is much larger, heavier, and feels quite different. Each device has its own slight limitations and also each has abilities missing from the other.
Outputs to control CV gear is a tall order. The data generated by the Soundplane is somewhat amorphous, because you can have any number of fingers controlling various parameters. It might be rather tricky to map the gestures to a particular CV output. Configuration should be very open, and would mostly occur on the host computer, depending upon resources. So, the scenario that would make most sense is for you to have a generic CV interface for your computer, and then tie that to the Soundplane via software. The options are so wide open that squeezing them all into the Soundplane firmware might prove too limiting. Then again, it's a good idea, so it will certainly be considered.
I guess my point is that you should probably think of the Soundplane A as more of a raw sensor that is tightly integrated with a host computer, and then your host computer acts as the central hub for controlling an endless variety of software and hardware.
There are a lot of questions jammed into the last reply!
As for foot pedals, are you requesting on/off switches or continuous controllers? They are each wired differently.
As for tracking errors in The Continuum, the technology is completely independent. I would not expect the Soundplane A to operate in the same fashion.