Thank you for your great feedback, and apologies for slow reply - we're in the middle of moving home (and the company) so I have been neglecting correspondence and the forum...
I could finally find use my Minilab MKII (no 5-pin midi output) and Ableton plus a legacy midi-usb cable to test Channel 34 - works well, you can add that to the list.
Cool!
1. I have the same issue as jluc in http://gechologic.com/support/index.php?topic=175.0 - I would plead for relative by default (suggestion for next release).
It will be there, also some new cool effects that I am working on.
2. While playing around with Channel 34, I noticed that the key were having an effect : the "keyboard leds" on the LoopSynth shows correctly which key is pressed, and mostly the sound/processing that outputs from the channel is very different. For the sake of completion, Line input only, some sort of gate effect (on-sustain-off) can be heard, with a slight pitch change related to the key press, as expected. Could you tell us what exactly is the effect (nothing in the doc).
This is the MI Clouds in the default, "granular" mode. If you attach a MIDI keyboard, the keys will control "pitch" parameters, and the knobs (if present), can control all parameters (in following order: texture, reverb, density, pitch, position, size, feedback, stereo spread, dry/wet, post gain) when configured in the "learning mode" as explained
here in the "How to set up MIDI controls" paragraph.
There is also "freeze" parameter that is linked to sensor S3, you can get a nice sound from ne mic or line input, freeze it, then play it with the keyboard. Or you can set up a MIDI sequencer at input, then feed monotonous sound into the line input, and the pitch-shifter will create a melody from it.
3. I tried playing the Minilab on various other channels ; it is somehow recognised by Channel 33, 34, 42, and maybe others.
Yes I think that by now it should be recognized in all channels that use the concept of pitch or chords.
4. Finally, I believe that an up-to-date MIDI section in the manual would help. Not talking about a long term wish: midi for controlling buttons B1-B4.
That can be done, now that we have the learning mode, not only you can assign knobs, but also pads. From my experience, many controllers that have pads simply send out note on-off events from them, like if they were regular keys. It is not ideal, but on the other hand if you have a controller without pads, only with keys, and you want to control Gecho's buttons remotely, you can train it to recognize some keys that you rarely use (the lowest 6 keys) for that purpose.
Many midi controllers have a 4x4 pads ; two rows could be dedicated to the short and long presses of buttons.
Maybe this would be handier than relying on note on/off, which can also be understood as long and short press of a button. But the training mode for pads currently only support 8 pads, that is not enough to cover 12 possible short/long presses of Gecho's 6 buttons. Ideally we would rather have a function per pad, covering also combination shortcuts, like SET+B1, RST+B4 etc... And to make it work for many different controllers, more complex configuration needs to be implemented, maybe in the form of config file on the SD card (much easier than adding another menu to configure it using buttons in Gecho.
I don't know enough about midi implementation by vendors, but would guess there is some sort of standard for assigning Midi messages to these buttons
There does not seem to be one standard but on the other hand there is not not too many ways how an engineer can approach this problem, so I believe if we have 2-3 cases implemented that would cover 95% of all controllers out there.
big picture: the Loopsynth could be a multi-function effect box that could integrate nicely with a studio
My original idea for Gecho (in 2018) was to make an amusing meditative box, weird and random, main motivation was for me to learn a completely new thing - how to build a DSP capable board, and teach it to process sound. There was no clearly defined roadmap of features... Thanks to all the feedback, it drifted to the more serious side over the years. But many things are implemented in a cumbersome way and it is very hard (and probably pointless) to redo everything at this stage, to have a better thought-out user interface. Also, the lack of display is a major problem, decoding those LED lights certainly is not fun for everyone. The potential to turn it into what you are imagining is there but indeed it all takes so much time (for the programmer) and I am afraid that it would only be used by 10 out of the 1000 people who bought it... Also from the economical perspective, for us to survive as a company we need to invent new things instead. Not saying that this will be left unfinished - but at some point we will need to draw a line for Gecho to not cross, and move all those new ideas to some stronger, faster platform with more memory - such as raspberry pi kind of Linux powered boards. For example Monome Norns is very versatile and in the shield version also quite affordable for all that it can do, plus working with custom scripts is easy enough to attract large community. That never happened with this project, perhaps as the low-level c/c++ is just too impractical to work with in a collaborative way, besides there is not really much headroom in the CPU or enough memory for all the ideas...
Hire someone?
That would indeed be great, not something we can afford now but if we had extra hands helping to build the synths, or even to test, pack and ship them (which has always been unbelievably time consuming) we could focus on the software more. Finding a programmer to help with expanding the functionality would be good too, but even less likely to happen given the costs of such work, and also all the overhead and complications of managing the development effort remotely. Sometimes it is faster and easier to just do something instead of explaining how to do it to someone else. Maybe I'm just too sceptical about it, coming from the IT background. Of course for someone for whom the coding for DSP is a passion and who is used to work independently, and is not afraid to dig into other people's code, could be a good fit - but such people usually have stable jobs or own projects to work on full time (this is a company of 2 and a lot would need to change in the world / amount of sales / cost of material, before we can generate a 3rd salary).
Thank you for all suggestions, and I hope to have the update ready later in the summer.
