Firstly, and i do not design modules and would never claim that i can do any better, BUT: this tbDSP really looks a bit ugly. Even granted that the panel design is probably beta, the placement of knobs feels disproportionate. Maybe not the final design, who knows, but if it stays like this, they should have consulted someone who can do proper panel design.
Otherwise i quite like the idea of user-definable modules. The nord modular is probably the only VA that I really liked and used. Of course, a lot depends on how the programming is done, and I am more in favor of a simple high-levels design – such a module doesn’t have to cover everything, also the nord modular doesn’t, it just gives a bit more flexibility that a usual device.
And for those who want more in-depth programming: I really do not see much difference to re-programming a MI module. The code is there, the dsp is reasonably powerful. The userbase for programmable modules will remain neglectible anyway.
What puts me totally off of the idea of laptop-like dsp in a modular: I still have few old cheap and cheerful synths, stored away, and sometimes I discover them again and power them up … and they work! Any piece of software I had at the same time is long gone. I really want a synth to function independent of whatever Apple & co decide to put into their latest update. And I want it to function in 10 years from now. There are some nice sequencers on the iPad also. But any update can ruin them, anytime.
Bottom line: for me, synths are still something that last, unlike apps. The nord modular is still surprisingly functional. But I would not trust something like the tbDSP to be up and running in 10 years from now. Maybe this is an irrational constraint, since I also buy laptops that I know are obsolete in a few years, but I wouldn’t do the same with a synth.
I think that most people who write libraries assume that the more a library can do, the more “difficult” it must be to use. So most of these “easy” libraries are unnecessary hampered by bad design choices. This leads to bad choices on the part of the user. At least in my experience, and that is not limited to sound libraries.
I honesty would not expect a small business to be able to make a full-featured library when they just release a product, but they could be better. If you even look at NI’s Reaktor they only recently did a major overhaul to how users can find and implement patches made by others and they are a massive company. Not to mention adding more patches they made themselves.
However, a cheaper cost always helps to bring in people who may be scared of wasting the money on a device they simply can’t use. Or think they can’t use.
In my experience with Arduino, most tutorials will teach very bad and inefficient practices for handling simple input. These “basic” lessons then carry over to the users more “advanced” programs. It is a never ending cycle.
Double post… And on a big rant too!
If you want a computer, get a computer.
Anything with a programmable processor is a computer.
Shit, all the modules i designed are computers……well, not the Multiple. But i was tempted……
Don’t worry Frank, there are some people, like myself, who believe that control messages should be 100% digital, or at least mostly digital. A big part of several sounds is how they change, and a DSP CV module would be much smaller, cheaper, and easier to program. No need to learn audio oscillator or filter modules there.
@6581punk: Ah yes, the Owl module - I’d forgotten about that. If it really can run PureData code, then it will be quite different to all the other modules discussed here, simply because the barrier to end-user hacking will be so much lower. The need to code in C or C++ for just about everything else is not so much the issue, but the need to have a reasonable understanding of DSP techniques to do anything useful in the audio domain is a problem (or at least it is for me…). No so much of a problem if you are just mucking about with CVs and gates for modular control. Puredata hides all (or much) of the difficult DSP stuff from you, which is why it and Max/MSP (and similar audio processing frameworks) are so much more accessible, and much more widely used, than just C/C++, for sound design.
I think some people just want a software equivalent of circuit bending.
@6581punk: If your code doesn’t compile, the unit will stop functioning permanently?
Or do you mean a distortion, a ring modulator, and if you want to get fancy an envelope follower?
@6581punk: You can software circuit bend: just edit some parameters on MI source codes and hear the changes
Or just MIDI-Poke the Ambika!
There’s an interesting discussion thread on MW about running arbitrary Csound opcodes on the Qu-Bit Nebulae, which is an open-source audio-playback, looping/granular Eurorack module built around a Raspberry Pi running some customised Csound code, interfaced to a custom Arduino board to handle the I/O for CV, LEDs, MIDI and audio conversion (yeah, it is not hi-fi, but it isn’t too bad, either - listen to some of the examples below). However, the RPi in the Nebulae can run any Csound code, subject to CPU limits (the RPI isnt’ very fast, but it isn’t a slug either), not just the Csound code that Qu-Bit adapted for this module. Csound has been around forever, but should not be dismissed as obsolete - its pretty deep, while remaining fairly accessible to anyone with a modicum of programming skill. The results are interesting, including FM synthesis, a multi-oscillator engine, formant vowel synthesis, and (polyphonic Karpus-Strong “plucked”:https://soundcloud.com/janefreiheit/qu-bit-nebulae-plucked synthesis, the last two of which are also implemented in Braids. OK, “this”:http://www.qubitelectronix.com/#)polyphonic-oscillator/cbou isn’t the Braids WTx4 mode, but it is still pretty interesting.
The issue, which is immediately apparent from the MW thread, is that the Nebulae user interface is not polymorphic, as we’ve been discussing. Nonetheless, I am suddenly very interested in the Nebulae, even though the hardware is not DIY (it could be - they have released the schematics under an open-source license, but not the PCB design files). However, the software is entirely open-source and, as demonstrated in the MW thread, eminently hackable, with just some familiarity with Csound.
Edit: The Qu-Bit people are running with this, and seem to have recruited a Csound expert to work on exploring more use of Csound on the Nebulae, as documented here.
The forthcoming, open-source Owl module, which apparently will be able to run PureData code via the Tannhauser compiler, will also be a compile target for Faust. No, not the krautrock band, but this. See also the OWL announcement for more details. This looks very interesting. The OWL device (both the stomp box and the announced Eurorack module) uses a Cortex M4 processor, the same as the forthcoming MI DSP module(s).
This does look interesting, I have to say. How useful it is may depend on if there’s a way to interface the module with external control modules though. Some kind of system whereby you could easily build your own i/o and control modules to plug into it would be really good, I think. If the module is limited to a couple of ins and outs, and a small number of controls, that’s going to severely limit the ergonomics of the unit.
@toneburst yeah, have a look at this video, which briefly shows the modular version of the OWL pedal, with CV control of the 4 programmable parameters for the device, plus stereo in and out. Thus, you can, in theory at least, write DSP code in C++ (difficult) or PureData (much easier) or FAUST (also much easier), then compile them and upload to the device. The Tannhauser thing converts Puredata code to C++, and I think FAUST does the same - both are high-level languages that make writing DSP code a lot easier (which is good for DSP ignoramuses like me…). Four CV-controllable parameters seems like enough to get started - plus two channels of audio! Nice. I want one!
@BennelongBicyclist does look good. I’d like to be able to plugin in more i/o though. A collection of trigger outputs and a clock input would open up possibilities for custom sequencers. It seems to be more biased towards audio-processing, so maybe that’s not so much of an issue. Having said that, more audio i/o would also be handy, so you could send audio out for external processing, then back in again, aux-loop style.
Nobody is ever happy on here
Someone makes a product for €400 with limitations - people not happy due to limitations.
Someone makes a product for €800 without limitations - people not happy due to cost.
Hardware always has limitations due to cost, software doesn’t have so many limitations on a computer.
These digital all purpose things are a niche on a niche platform.
@6581punk very true. I’m just a born moaner
It’s interesting there are several different approaches to the same basic product appearing now though, and I’m interested to see which ones fall by the wayside, and which (if any) properly take off.
Well I think people on here have some serious addiction issues the amount of gear that seems to be bought then immediately sold is incredible haha.
I’m guilty of it too, but I move between hobbies depending on the time of year. So being summer and in Britain I’m soldering all the time since winter is much dryer (joke, I’m riding my mountain bikes).
But anyway. Seeing how some professionals do things live these days shows that laptops (especially Apple ones) are king. I think this is a shame in many ways, but it is the most flexible tool if you can live with the risk of it crashing.