Cherry Audio Forums

Hi,
doing some experiments with the Module Designer. Nice tool overall!
Have some questions (on second thought - probably more feature requests ):
1) Is there a full API documentation somewhere? Or an option to jump to the definition of the in-built classes? Something along the lines of standard Javadoc would be fine, so we can click on links to all internal and external classes
2) Is it possible to use external code editors? The internal editor is okish but of course no match for IntelliJ&Co regarding navigation, code completion etc.

Now these are definitely feature requests
1) It would be great if we could run the inputs and outputs of our modules at different rates (either a fraction or a multiple of audio rate). So the ProcessSample function is called at the least common multiple of these rates and slower inputs/outputs would e.g. just provide n times the same value as an input or sample every nth value as an output (when n is the input/output specific relative rate). If two modules with different rates are connected they would e.g. use sample and hold for decimation or repetition as needed.
Would e.g. like to build a module with 16 cv inputs at standard audio rate and one output at 16x audio rate that sends the interleaved inputs on the output and another 1 cv input 16x audio rate input and 16 standard rate cv outputs module that multiplexes the one "multi-channel" input to 16 outputs.
Dedicated multi-channel cables (at constant audio rate) would also allow this particular use case. Multi-rate processing would be more universal though, allowing multi-channel mux/demux, control rate subnets (that only have to run at audio rate at the boundary towards the audible modules), super low aliasing subnets that run above audio rate and are only downsampled once (instead of between each module) - etc.
2) Please consider to add alignment tools inside the interface designer. Currently aligning controls is a little fiddly (had mostly to use the numerical input atm.). E:g. look at how Max allows to align the object boxes with magnetic helper lines.
Edit: Found grid and align-to-grid features - no relative alignmet but already a big relief.
3) It isn't obvious for the user that a product is not defined by the project/module name but by the package name. Initially I wanted to put several related modules into the same package. When uploading I saw that they overwrote each other. Wouldn't Module Name be the more intuitive unique product key? (Also considering that this is the name under which the module will be visible in VM).
Edit: Ok, two modules with the same name are apparently allowed (so two devs could call their module "Oscillator". Thus using the package name as unique key makes sense. Could we perhaps use the combination of package name and module name, to reduce the "surprise overwrite factor"?)
4) best add some option to delete uploaded products and builds again (at least when they are still in development state).

Just to emphasize why multiplexing/multi-channel is imho essential for building anything polyphonic:
Tried to protoype some modules and put them together to build the most basic 16 voice subtractive synth imaginable. Not really sure whether this is practical..
Either you have to give up modularity (by stuffing everything into one module or hardwiring some modulations to some MIDI messages - by essentially adding a MIDI in to each and every module) - or you have *lots* of wires. (Happy debugging if one cable is misplaced )

NothanUmber wrote: ↑Sat Oct 20, 2018 8:20 am 1) Is there a full API documentation somewhere? Or an option to jump to the definition of the in-built classes? Something along the lines of standard Javadoc would be fine, so we can click on links to all internal and external classes

We don't have detailed descriptions of all the APIs yet. This is largely a matter of getting the developers who made the APIs a breather so they can work on this. We do have signatures for all the public APIs we've written, though, in the "Library" section in the module designer, just to the left of the code editor. The tooltips include return type & arguments, and you can also see API signatures by dragging & dropping them into the code editor.

NothanUmber wrote: ↑Sat Oct 20, 2018 8:20 am 2) Is it possible to use external code editors? The internal editor is okish but of course no match for IntelliJ&Co regarding navigation, code completion etc.

The auto-generated code makes external editors tricky. We could probably work out a way to handle this, but I think we'd rather spend our time improving the editor itself. We're working on lots of stuff that should make its way into the editor in the coming months - adding user-created functions to the 'module' pane, tooltips to show variable types, jumping to variable definitions, etc. If there's anything you're particularly keen to see, let us know.

NothanUmber wrote: ↑Sat Oct 20, 2018 8:20 am 1) It would be great if we could run the inputs and outputs of our modules at different rates (either a fraction or a multiple of audio rate). So the ProcessSample function is called at the least common multiple of these rates and slower inputs/outputs would e.g. just provide n times the same value as an input or sample every nth value as an output (when n is the input/output specific relative rate). If two modules with different rates are connected they would e.g. use sample and hold for decimation or repetition as needed.
Would e.g. like to build a module with 16 cv inputs at standard audio rate and one output at 16x audio rate that sends the interleaved inputs on the output and another 1 cv input 16x audio rate input and 16 standard rate cv outputs module that multiplexes the one "multi-channel" input to 16 outputs.
Dedicated multi-channel cables (at constant audio rate) would also allow this particular use case. Multi-rate processing would be more universal though, allowing multi-channel mux/demux, control rate subnets (that only have to run at audio rate at the boundary towards the audible modules), super low aliasing subnets that run above audio rate and are only downsampled once (instead of between each module) - etc.

I'll show this to the other developers, along with that highly illustrative screenshot.

NothanUmber wrote: ↑Sat Oct 20, 2018 8:20 am 2) Please consider to add alignment tools inside the interface designer. Currently aligning controls is a little fiddly (had mostly to use the numerical input atm.). E:g. look at how Max allows to align the object boxes with magnetic helper lines.
Edit: Found grid and align-to-grid features - no relative alignmet but already a big relief.

I agree, more alignment options would be really useful. That's on the to-do list.

NothanUmber wrote: ↑Sat Oct 20, 2018 8:20 am 3) It isn't obvious for the user that a product is not defined by the project/module name but by the package name. Initially I wanted to put several related modules into the same package. When uploading I saw that they overwrote each other. Wouldn't Module Name be the more intuitive unique product key? (Also considering that this is the name under which the module will be visible in VM).
Edit: Ok, two modules with the same name are apparently allowed (so two devs could call their module "Oscillator". Thus using the package name as unique key makes sense. Could we perhaps use the combination of package name and module name, to reduce the "surprise overwrite factor"?)

There are probably ways we could make the importance of package names more clear. I'll think about this.

NothanUmber wrote: ↑Sat Oct 20, 2018 8:20 am 4) best add some option to delete uploaded products and builds again (at least when they are still in development state).

The ability to delete modules from development should be coming soon. The back-end developer is juggling lots of stuff at the moment, but we know this is important - it's a hassle for us, too.

Thanks for the feedback! Let us know if you have more issues/ideas.

Thanks for your feedback! Regarding editor features: The most helpful would probably be auto-completion - that way you also easily see which methods an object provides by just writing the "." which opens a list of possible methods to call. Or when I enter "(" it shows the list of parameters with their types.
Additionally a shortcut to show the javadoc for any class is very helpful. And last but not least a shortcut to jump to the definition of the method below the cursor - or the other was around if I am at a method definition already it shows all usages for that method. (IntelliJ even can show the definitions inside files that are only available as jar binary by using a built in decompiler).
Just play around a little with the Community edition of IntelliJ, you will get many suggestions how to improve the editor

Have played around further with the MPE controller poly synth idea. Multi channel voltage cables (or even better multi-rate support which allows us to easily implement multi-channel mux/demux and more ourselves) would of course be most awesome.
A compromise to minimize the clutter might be to modulate the modules via midi. And then to offer some modules that convert voltage to midi, in the case you still want to voltage control the modules. (The MIDI cable is essentially already a "multi-channel cable").
Here how this would look like: In the upper row the oscillator, filter and amplifier/mixer are controlled by midi (so midi goes into any of these modules and only the audio is forwarded between the modules via 16 individual cv I/Os). In the lower two rows another copy of these three modules is controlled by voltage by converting voltage inputs to MPE (v2mpe converters from left to right: note+velocity,pitch bend for oscillator, pressure,expression for filter cutoff+resonance, pressure for amplifier volume). The ADSR would be baked into the amplifier in that case - for voltage control this would be switched off via "velocity=attack off", because voltage should be fast enough to model the full envelope, including attack. For MIDI the envelope would consider velocity from the note on (as MIDI event rate is usually too slow to model fast attacks just with e.g. aftertouch).

Question in that regard: In order to make this viable, internal MIDI events would have to also be generated and handled at audio rate. My understanding is that, if I generate and handle MIDI in the ProcessSample function then I can use the MIDI I/O to send/receive midi events at sample rate between my modules, is that right? (Speaking about generated MIDI like in the example above - if I receive MIDI from external controllers it is clear that the speed of the controller is the limiting factor).

Please also consider the "poly rack" suggestion from the bottom of this thread: viewtopic.php?f=8&t=14

That would be much better than "polyfying" the standard modules as it would also work with every other 3rd party module.

+1 about the poly rack !

Thank you for all this amazing feedback. We are discussing this possibility right now. We especially like the polyjack/polycable idea. (=