Okay, but it would be interesting if the API you develop allows developers to do this kind of work.
I saw something similar using “Control Chain” of MOD Devices. One developer ported the Control Chain client protocol to ESP8266, connected an iPad into ESP, developed a program for the iPad and controlled the MOD Duo with the iPad.
In Raspberry you would not need ESP8266 or Control Chain protocol, just that a library has a way to control the equipment.
So if you decide to develop a protocol for controls Zynthian with Arduino over serial with USB, allow the solution to be encapsulated so that a developer can use this protocol via Bluetooth, http, or even make the protocol API functions accessible (documented and tested) so that developers can directly use this API
Hi all,
I have read the different posts and i think it’s indeed a very good idea to see if some of RPi’s handling overhead like GPIO to an external device / Mirocontroller. The advantages are obvious öike more “free” pins on the RPi and (maybe?) improved latency - if that is still considered a major concern also more functionality.
Major problem will be to discuss (see what’s already presented) and then decide on a durable modification which would also allow more devices to be added in the future without turning the existing completely upside down - that wouild indeedf frighten away other new (“world-wide”) users.
This leads to the proposal to focus on existing bus structures like I2C or SPI, CAN or else, for which basic knowhow is around not mmaking it necessary to develop everything from sratch. As one hardware candidate I’d like to propose something like Teensy 3.2 or 3.5 which by far outperform the arduino family, and they also have other advantages like tolerating 5V input etc. However, other mothers also have beautiful daughters ;-))
If can be of any help as a bloddy beginner, I’d be glad to participate, especially when my first ZBox (Standard) is up and running (will send some comments about that in the next few days).
My explicit wish would be to make a quite general hard- and software expansion with best computing power which would allow easy addition of things like Jofemodo’s encoder to MIDI develoquitepment (why only MIDI?), breath controllers and the like. BTW, has anyone already inpected solutions like “Virtual GPIO PC” for those for which even RPi3 is not powerful enough ?
So, be is as it is, ZBox development remains to be a very exciting project,
CONGRATULATION !!!
ToDo: extend Zyncoder library to support this - not really easy…
External uC controller via USB-serial protocol (modular way, for normal makers)
ToDo; specify protocol, extend Zyncoder library
Raspi-shield/hat with MCP23017 (=“encoder interface”) and MIDI (In/Out/Thru) and seperate Encoder PCBs - (perhaps all pre-built)
much more difficult to build, but perhaps an option if it can be ordered/manufactured by a specialized company
in fact this is nothing else than the current designs, but if can be ordered pre-build, only plug and play should be necessary.
For 3.) my thoughts are going to a shield where the encoder pins are plugs on the shield an you only have to connect the encoders (like Ebay Rotary Encoder on PCB).
Hi Zynth addicts,
as usual C0d3man has given us a pretty clear structured way forward!
just want to add:
re 1) there are already many descriptions for adding game controllers, you can find them with google “game controller for arduino”, “game controller for teensy” and so on, so implementing this does not need to start from scratch…
re 2) maybe for best useability, this option could use a staged approach for the introduced new mikrocontroller, like:
… time-critical response: use interrupt drivers for input and for reactin just as well
… less time critical: use a mix of polling and interrupt
… not time critical: use polling only
re 3) this option could also supply some storage area where the selected parameters can be stored in like a buffer which could then be read by other RPi programs. This would then mean to implement some memory and logical (I2C or SPI?) access structure on the extension interface which can be assessed by the RPi…
Another question to solve is definition of a min/max number of GPIO pins which could then lead to the decision how many MCP23017 ports should be used or if ports e.g. on a Teensy 3.5 could be sufficient (and maybe also expandable later) …
A reasonable starting point for “2” and/or “3” could be a durable definition of exactly how MCP or Microcontroller (preferred?) can be implemented . If such protocol is agreed on, then there are many open options about how port expanders or other mikrocontrollers should be connected to RPi without too many changes to existing RPi software …
Again, just some humble thoughts for best possible solutions…
The Rpi3 has just enough GPIO-s for all the 4 encoders and buttons, so You don’t need any port extender HW, like the MCP23xxx. My box works this way. This thought is for the “Encoders via GPIO” part of the topic title.
Yes - this is the default way - my Zynthians also run with encoder<->GPIO. This is a really nice solution, but also complex to build. And there is another problem: Some soundcards (like PiSound) may need some of the GPIOs used for encoders. So (IMHO) the MCP23017 way is a really nice one!
Hm - as a very easy version I thought that the game controller should be directly connected to the RPi? So absolutely no prebuild hardware needs to be created for testing/using Zynthian:
MIDI-USB-Adapter/Keyboard
RPi(2/3)
HDMI-Monitor
Hifiberry (or other soundcard)
Game controller
But the effort for writing code for the GUI/zyncoder to use game controller instead of encoders maybe high.
I don’t see any time critical problems when using normal python code (without IRQ handling)… it’s “only” for the GUI
Maybe I don’t understand what exactly you mean, but I don’t see any needs for creating a buffering here. The MCP23017 approach is currently done by @beckdac and a patched zyncoder library can be checked out at his github repository.
I think that the current design of the GUI and the handling of the Zynthian should not be touched. The interface for control the Zynthian is the zyncoder library. If there is a need for a game controller, so the zyncoder library has to handle the stuff how to map this to the internal controlling structure of Zynthian. Also a uC-protocol has to be implemented inside the zyncoder library.
My starting question was: How to make building a Zynthian easier and robust for everyone. So 1.) seems to be a solution for “easier”. 2.) and 3.) for “robust”… really tricky…
My rough idea is: creating a Fritzing circuit with MCP23017, MIDI I/O/T and plugs for 4 encoders. Perhaps someone can prebuild them so non-maker users can buy a complete tested circuit (prebuild PCB, encoders, cables for encoders). Or the makers can do everything by themself.
hello Holger,
firstly - thanks for the clarification, and I fully agree to them, I think - as far as I understand it all ;-)))
Maybe I was a bit unlear with what I meant, so here is another try for potential inculusion of some “external” intelligence in something like Arduino or (preferably?) Teensy 3.2 or 3.5 and please do accept my apologies for the case you find my proposals not feasible or even unpractical …
I’m not concerned much with the performance of the GUI, but rather in creating some STD-protocol for different controller types, like different “business cases”:
… encoders - ok Zynthian knows about these pretty well, but what about 20/22 steps in one 360 turn of the knob as compared to multiple turns before the value is read (I call it “tuning the knob”)?
… Bank of encoders like Jefemodo’s new box with 8 knobs for 24 parameters - read them separately or as a block from some buffer - direcly or via MIDI controller message format?
… poteniometer strips or breath controller to simulate a string or wind instrument - using direct play control just like aftertouch, probably also in different formats?
… creating (offline) multistep envelope value presets which are stored and called up later during actual play (one of the charms e.g. of CSound / Chuck);
… ok, there may be even more examples, but my main idea is to have a set of routines / a library which could handle all these instances and bring it into some (multiple format) standard in an external uP befor the main RPi software reads and executes what’s there …
… well maybe these ideas are not realistic for inclusion in just one piece or software, so probably each single case / controller / format has to be dealt with in a separate routine, but even then it would be helpful if you wizards create some king of “Howto”, “Do’s and Don’ts” etc to accomplish a more or less compatible standard list of “drivers”, or maybe even define some sort of software bus structure like in the old 8080 uP days…
… Oh, btw there are several open source examples for adapitng a Nanchuk or Wiii controller in the net - if you want, I can try and dig out the links…
this much for now,
thanks for l"listening" to these crazy ideas,
and apologies for that many words,
regards, Tom
Ok, here’s another crazy idea. Could we map a USB QWERTY keyboard to control the Zynthian UI?
I see that there is a discussion ongoing about the feasibility of using Midi CC messages to emulate the encoders. There are many different Midi control surfaces out there & it seems difficult to come up with a solution that fits all.
OK, emulation of the encoders would be poor. I imagine having a key to emulate one click clockwise & another key for one click anticlockwise. Navigation would be a bit s-l-ow.
But, it would allow newbies to try out Zynthian before making a full build. And it would open the door for people to create their own custom HW. Making a USB keyboard with an ATmega32U4 based Arduino is easy. Or you could even break apart a PC keyboard and use the controller from that.
lower F# could do Channel Down (Velocity might even adjust the speed of the repeated presses )
lower G# could do Channel Up
lower A# could do channel Select
lower A could do Back Down
lower B could do Back Up
lower C could do Back Select ( This would sit under the left hand thumb)
Higher E could do Select Select (This would sit under the right hand thumb)
Higher F could do Select Down …
Higher G could do Select Up
Higher F# could do LS Select
Higher G# could do LS Down
Higher A# could do LS Up…
I think I start to understand what you mean
Also I think this definition would be not be easy - a kind of “one protocol for all” (I thought OSC would be this protocol…???)
Hmmmm - really not an easy task - and I must say that I personally think I am not the right person for this. This seems to be a seperate project. You have to start to write a kind of RFC for multi-protocol-interacting with music devices. I think there were several approaches made by big companies. My first idea for this is using OSC. But the problem of OSC is that there is no agreement about how to use the namespace (AFAIK).
This might be helpful, but currently my personal problem is not how to implement the hardware communication, but how to represent the usage of the encoders by such a controller.
Thanks for your ideas and comments! I think everything is quite helpful to get (me) out of a restricted view.
Regards, Holger
P.S.: Sorry, but my english is not the very best - so sometimes my words may not sound like the things I would like to say…
Yes - also an option! Especially the MIDI keyboard option seems to be a nice idea! I think I must start something like a “Howto” like @music.friend wrote. So we can try to define how the communication with the GUI should happen.
Currently I have not much time - perhaps we have to think some days about this - but in a few weeks I will start this project.
I’ve been quite busy the last weeks with the Maker Faires and moving “Made BCN” (where “Zynthian Labs” has its place) to a new and bigger space.
Now that the Maker Faires ended and “Zynthian Labs” is working again, i can concentrate in development and next steps. Great!
Of course, i’ve been following the dicussion about the UI Control and i really love some proposed ideas.
My vision is this:
Full Zynthian Boxes have 4 rotary encoders with switch. This is the “official” UI. To ease the building proccess, i’m designing a new All-In-One PCB, that uses the MCP23017 to manage the 4 rotary encoders + switches. Also, it includes a full MIDI interface (IN-OUT-THRU) with optocouplers in all ports, as proposed by @Imager:
This PCB will be available very soon, along this summer. Of course, i will release the “source code” too. This time i’m using Kicad, a nice schematic and better design practices than before
2.) Full Zynthian Boxes also have a ScreenTouch interface, that allow to navigate and use the GUI. It adds some extra features, like X-Y controller and MIDI learning.
3.) Remote Control Protocols must be implemented. Both, MIDI & OSC.
Regarding MIDI, channel #16 will be “optionally” reserved as Master Control Channel and the next commands will be implemented:
GUI Navigation => note-on interface proposed by @wyleu is very interesting … jeje!
More?
MIDI Master Control commands will be configurable from the Webconf tool and GM & Roland styles will be available too.
The OSC API have to be defined. I will make a proposal in the next days/weeks. It should include low-level commands that emulates rotary/switch events, and higher level commands, like loading snapshots, getting list of parameters, changing parametes value, etc.
Of course, a Zynthian Box could omit the rotaries, or the touch interface, or both!! and be controlled remotely using MIDI or OSC. In such a case a simple RBPi+soundcard is a basic Zynthian Box, as far as it runs the Zynthian software.
Hey, using a keyboard would also be great.
couls also be one of these tiny bluetooth ones which some people have for their tv media centrer,
and i wonder if ift makes sense to simulate (yes, maybe) or replace the encoders (mhhm, maybe not that perfect)…
and commands form a keyboaerd or keypad could help to activate a complete group of eencoders or load / save banks / presets - possibilities are endless …
regards, Tom
also a nice idea !!!
many commercial keyboards are diong this, too
commands played as a midi melody, will sound a bit funny :-))))
and you have to remember which key represents which command - that is somewhat tough for an old guy like me with not many memory cells left ;-)))))
Ha, you caught me again by surprise !
I did not recall “OSC” (and “Faust” wich you mentioned earlier) which I have to discover and learn about …
Until now, the group has discussed tons of valuable ideas and it looks like it is now time to think and sort, also including what Jofemodo
is about to pull out during summer. In his “announcement” he has already proposed some first stwps into a more staged approach like
the use of channel 16 and CC 7 for volume control., and I feel that such (optional?) agreements are the best way forward.
In addition, the project is using some “database”-like setup of hardware in the webconf-menus, so why not use a similar thing for driver/ controller/ preset setup ?
OK,having said that i must confess that now when i have sucessfully finished my first Zbox hardware, i see the many clouds of software options, setup and use coming up, so for my part i’ll be more a silent listener to the extension questions until i have more experience with the software, too…
one final “final”:
building my first Box, i have tried to add a few drawings (png) for even better clarification of steps, but I have not figured out how to “post” them.
Since the major descriptions in the wiki are from you and jofemode, sholud I send these to him and to you for decisiobn if these additions could be of any value ?
Super stuff !!
just some questions for more understanding:
… the new PCB will use same GPIOs as the "reference kit?
… added controllers communicate after having passed the MCP 23017 with the RPi via I2C; polling, or interrupt ?
… how is your new 8/24 encoder box integrated ((midi/osc or other?) ?
Please tell us when the parts % software is ready - i would even now like to order an exemplar ;-))))
and again a big thank you for putting out all this excellent stuff !!!
rgards, Tom
The wiki is a wiki
So it’s opened to the community. You can edit contents or add new ones. Please, feel free to contribute to the wiki!! And of course, all the people in the community is invited too!!
(I also have an Arduino shield for ControlChain but no time for testing/using).
)
