Next U-HE Plugin...

[Urs]

It will sound absolutely smooth in Repro-1 as well. But it took one developer four months to tackle the issue.

It'll take some time, hence the rough estimate of what can be expected in the near future (read: maybe this year).

I love how dedicated you guys are to nailing every aspect of this thing. I'd have never of guessed something as seemingly simple as that could take four months to get right, but I'm glad you're that committed to it. Take your time...

Thing is, when the pulse waveform modulates its own width it's like "Oh, gotta jump up now. But oh, now I have to get back down. Which, oh, makes me jump up again" and so on. This happens in megahertz regions in analogue hardware - there's a delay of a few nanoseconds, just the time an OpAmp needs to settle. The thing jumps up and down, but all we hear is a smooth sawtooth-ish ramp.

In software, one can't solve it "zero delay feedback", as it leads to equations with multiple solutions. One needs some delay, which is - of course - one sample. But then, in order to get this as smooth as hardware one has to oversample hundreds of times - way too expensive. So we explored many, many ways to find good solutions until we ha done that works well even when OSC B has multiple waveforms on and self-FMs.

Similar issues will arise later with other things we've planned, but Repro-1 is probably the worst case scenario for many of those.

[david.beholder]

At least it would require a more thought-through hardware design, and less cablework. Cables and connectors are the plague for a device that's supposed to go on stage or something. The less connections, the better. I can imagine something like a rPI or Banana PI for the SW, an SPI-based Touch LCD, a USB sound device or a HIFIBerry board, and an Atmel-based µC like an Arduino for the hardware-interaction part. My personal experience with buttons, switches and encoders using a non-RT OS were disappointing, a dedicated µC is mandatory for tight and reliable operation. The two parts could greatly interact using I²C or the SPI interface, which has been done a thousand times in other fields, and it works.

I have several different projects with several different boards incl. Beaglebone, Arduino Mega... There are no actual problems with digital buses, matircies, multiplexors - they are very good described and very efficient. Say I2C could work on 1 mhz speed i.e. 100 encoders would give data in audio rates. You could have I2s or SPI ADCS and chains of pots also at audio rate. You could get 100khz but it's never necessary to go above 1 khz. Pi or Beaglebone has RTOS/NoOS solutions as well as may others. node.js and python are speeding up development but they don't scale and in the end C/C++ code is necessary.

[sascha]

You name it, and at the end of the day it's a considerable amount of work. A professional product requires a professional toolchain and is nothing one or two people can do on the side. Apart from the fact that the work doesn't end with a manufacturing process. Au contraire.

[pdxindy]

I have different templates in Novation Automap for different OSC modes. Basically first page is different and the rest of the pages are very similar: filters have very little variation and envs/lfos are always the same. So it's very easy to remember and use quickly.

There are like 170 parameters in Diva... there is the modifications page, the trimmers page, a single LFO has 11 parameters.

The Digital Osc alone has 23 controls.

Sorry, but Novation is a nightmare of pages and switching with that number... I would not possibly remember which parameters were on which page, or what parameters were in the add modulator, or which filter model I had selected, or what button did what.

It is nowhere near the experience of a simple knob per parameter hardware synth.

I wonder how well the Arturia Matrixbrute will work as a midi controller?

It has enough controls to be a compelling possibility. I'm very much looking forward to trying one.

[MitchK1989]

I wonder if you could at least use the matrix brute matrix+digital encoder as a 256 parameter controller, regardless of the other knobs.

[pdxindy]

I wonder if you could at least use the matrix brute matrix+digital encoder as a 256 parameter controller, regardless of the other knobs.

Since there are presets, does that mean all the knobs send midi? (at least internally?)