Reading this with interest as I have envisioned something quite similar: multifunctionality with stored parameter values. Haven't dived into making this work as I am still finishing the hardware part, but will post my progress (and -more likely- calls for assistance) on here as and when it happens.
Hardware interface concept question
brasso
#4
Dear Gavin,
A very good point. That settings have to be remembered and should not jump to the controller positions when you return to the group is off course a prerequisite. It would drive one mad if that wasn't implemented. Imagine having to set everything up from scratch every time you go back to a certain group! All sorts of little paper notes would be lying around the place containing ones last settings. Or youd need a spreadsheet to keep track! 
"Backwards compatibility" of settings is of course one of the classics of menu driven sytems.
The best feedback solution is that of mechanical automation. You reload the settings and the tool jumps back to the last setting you had when you left the group. I still work with the Roland VS 2480, which is / was an almost perfect mix of hard and software in recorder-land like the Axoloti is in synth-land. You go back to a certain page and all the faders jump to the previous setting, even without intermediate storing.
A good alterntive are pots with led-rings, which where, if I remember correctly, first introduced by Clavia / Nord.
Already a lot less elegant is the classic solution in which the previous value is kept untill the controller is moved over the previous setting. Since I am not aiming at building a very high tech controller that will however be the most practical option, especially since it is compatible to every standard type analog control device out there. As long as you have the screen on standby it will be less of a disadvantage anyway because the previous settings will still be visible on the screen until you change something, automatically giving you the sort of visual feedback you mention. During stand alone use that advantage will of course not exist but even then the "through previous setting" option will be the best purely software driven solution. Better then "jump directly to controller position" anyway.
To me the good news is that this sort of stuff is possible in Axoloti. Could you explain how to implement such an approach? Best would be a sort of step to step guide. I am quite good in conceptual thinking and quite versed in synth lore and hardware use but I am still a terrible Axoloti novice!
Marc
brasso
#5
Hi Mc,
Well first there is the idea and then, paraphrasing a dutch saying, there comes the moment when the fool asking needs more then 10 wise men to come up with the actual solution. Your reaction however proves there are more people out there who would like to use such an option. It actually surprises me it isn´t already a more or less common approach. 
Marc
Blindsmyth
#6
@Rbrt has an object called tablestore that could do the job:
Good thing is all the values are stored in the table wich is good for default settings or presets.
As for feedback I'm trying atm the midi fighter twister and the behringer x touch mini wich both have led rings for feedback. another option is livid base but I that touch faders don't work well with sweaty fingers.
brasso
#7
Yeah, somehting like that, providing a behind the scenes "automatic spreadsheet" that takes the hassle away.
My inroad is a purpose built hardware interface but a per MIDI solution will of course still have the same data management issues.
Please elaborate.
Gavin
#8
I would like to insist on at least asking, would you consider using rotary encoders. Many forum members appear to be against rotary encoders, but it would be hell of a lot easier to implement your idea, than using pots. I Even posted examples on where I control 64 parameters with only 2 rotary encoders. And very easy to create the Axo objects required. You won't need a table to store values, you can just use a mux to redirect the signal.
MC_DETH
#9
Hi @Gavin
I have been trying different things with your rotary encoder objects -a great addition to the library- and I ran into some unexpected behavior which I can't seem to figure out. The integer display object won't scale across the numeric values when I rotate the dial, but behaves jittery and jumpy; going back and forth between a few values only. It will jump to the maximum set value (e.g.64) and keeps jumping back and forth between the highest values when I move the encoder instead of moving back towards 0.
Same thing happens with the encoder patch @matthewcieplak has posted on here. Have you come across this behavior?
Sebastian
MC_DETH
#10
Hey @brasso,
I am also looking to use the most basic version of preset recall through led light indication. I am basically looking to make this work using a rotary encoder and three led illuminated buttons, as my hardware enclosure is based on the layout of the xylobox by matthewcieplak: 24 pots, a two digit display, one encoder and three buttons with leds.
MC_DETH
#11
This is the concept (which still is a concept only, while I am slowly getting acquainted with basic patching). I am
Looking to create a four-step preset-saver/loader. I am trying to make this work through pressing combinations of three led-illuminated buttons and dialing a rotary encoder to select a load/store location. Added difficulty: I would like to be able to store presets relative to their patch. I.e. When using 'patch A'; all stores and loads automatically come from/go to a dedicated 'patch A' directory on the sd card.
The parameter controls are divided up into four groups of 8 potentiometers. Each group is indicated by one of the three button leds, except group 4 which is represented by all three leds lighting up.
When turning a pot, the corresponding button led (indicating group 1-4) lights up and the display briefly reads the pot number (01-28) after which its position value (1-64) shows on the display.
When a new preset is loaded, potentiometers that are out of sync remain unresponsive to dialing until their position is aligned to their individual preset value.
Save preset:
1. Keep button one pressed and briefly push button two.
2. Release button one.
Button two blinks.
Display blinks.
(To cancel, press button one. Buttons are back in current mode.)
3. Turn encoder dial to select storage bank (1-99) in directory.
4. Press button two to confirm.
Display stops blinking.
Buttons return to current mode.
To overwrite current preset, skip step 3
Load preset:
1. Keep button one pressed and briefly push button three.
2. Release button one.
Button three blinks.
Display blinks.
(To cancel, press button one. Buttons are back in current mode.)
3. Turn encoder to select load bank (1-99) in directory.
4. Press button three to confirm.
Display stops blinking.
Buttons and pots are in loaded preset mode.
To reload current preset, skip step 3.
brasso
#12
Hi guys,
Great to see you become so enthousiastic so quickly.
However: As happens so often in these hallowed halls a simple question starts to move in all sorts of hardly expected directions as soon as one posts it. So I do fear that it is already time to drag you back to the concepetual phase first, even if some of you might only go there screaming and lkicking.
I do not have anything against digital input devices, such as rotary encoders (with or without led rims) but please consider this:
If we look at the Axoloti in isolation we only have 5 available digital in/outputs. Working with 5 rotary encoders will quickly lead to the old mistake of trying to see the whole house through a letterbox. Every time you want to get aquiainted with any of the houses occupants or objects they will first have to be placed in front of the, all too tiny letterbox. This is actually what made most early digital synths difficult to stomage. The Yamaha DX 7, which promissed to be able to do everyhting but was a pig to master, immediately springs to mind. Believe me, I've been there.
5 inputs are very meagre in that respect anyway. Such stuff only tends to work well if you add a display directly above the controllers reminding you of the present address of the inputs. But that display would need a digital output from the Axoliti itself, bringing the number of digital input controllers back to 4. Then you'd need one controller to actually select the submenu, bringing the number of menu data input channels back to 3. Etc.. See where I am going?
Yep, I see 2 counter arguments coming anyway:
1 - MIDI can provide loads of control numbers and even work with data dumps. True, but the world is full of nifty and affordable MIDI control devices so why not buy one of them anyway.
OK, the best interface ever will never be marketed. So if that is your thing just go ahead an build a wall sized personal controller anyway. Been there as well.
I pesonally however have a clear reason to not go to MIDI. I am totally hooked on using polyphonic aftertouch and stuff. So MIDI already has enough trouble anaging pure musical input data when I am around. That alone will clutter up your MIDI data stream quickly enough and lead to all sorts of MIDI lag situations if you want to include a lot of addional traffic. So in that respect the direct in and outs of the Axoloti board are not only a bonus but can actually be a lifesaver.
2 - 5 rotary encoders could of course be used to work in conjunction with the analog inputs. So why not hook up all controls you want "permanent" acces to in your instrument to the analog inputs and add a small rotary coder matrix as an additional source for more esoteric parameters.. The rotary encoders could then provide an almost endless number of tiny submenus.
The disadvantage of that would however again be that one will loose oversight very quyickly. You'd again need lots of notes, overlay and spreadsheets to keep your mind from exploding. Thast is actually why I propased a "simple" 5 x 15 matrix. Anyhting more then that will be difficult to keep track of for mere mortals anyway.
But even if you would personally be able to wrap your own mind around an even bigger matrix: Will the Axoloti itself then not become cluttered up with all the data management routines needed for such a (theoretically) limitless system?
As a samller expansion on my original pushbutton selction idea this could however still be viable
Wrapping things up: I do have no qualms with using digital input dervices but I'd prefer it if we, at least for now, concentrate on ergonimically viable direct Axoloti hardware controllers, which are as we have already established limited to 5 digital ports anyway. In my opinion that makes an analog / digital input hybrid unavoidable.
Cheers,
Marc
brasso
#13
Dear MC,
Nothing wrong with this! So if preset management is important to you why not go for it? You could actually start up an additional thread to discuss this idea more widely.
For me personally it however is a less emmediate concern.
Marc
Gavin
#14
@brasso,
Its good to see you understand what you want, every ones needs are different....
I would strongly recommend you begin small, maybe 2 digital and 3 analog, so you can develop your proof of concept, and design it in a way so you can expand it as it all comes together and at that point deal with the Axo's limits.
I have ran into issues where I have asked too much of the Axo to drive controls, it was 32 selectable values using mux's, my goal was to get to 64, I found with the object setup I had, I would have to settle with 20 at the most, and this was without considering the size of patches likely to be used. So I ditched it and went with homebuilt midi controller.
Gavin
#15
@MC_DETH, I have never seen the behavior you describe.
Have you checked how its all connected ?
brasso
#16
Hm, as already mentioned I expect a practical limit depending on how much you can / want to set aside for such functions without taking too much proccesing power away from the really important things (like actually making musical noises). That only so few numbers can be processed does however surprise me. When managing a model Axoloti must be doing loads of such stuff in the background anyway.
Marc
Gavin
#18
@brasso, The "only few numbers can be processed" is not so straight forward. The objects I developed were designed in such away with 32 that it could be extended to the level I was seeking which was 64. Because of the approach I took, this itself added processing, even finding out 32 was too big. But my needs were different to yours. Hence why if I did it again, I would start with much smaller design to get to the goal.
I haven't seen anyone's projects yet try this approach, would be really cool to see if it can work. 
brasso
#19
Hi Gavin,
You'd have to eloborate a bit further for me to fully get what you mean. What we where discussing here is more of a pure data management problem: How to store and get back to previous settings in a submenu. In that case no extra processing would be needed. Only a sort of lookup table.
Gavin
#20
Apologies @Brasso,
Somehow I am worried I could be steering you incorrectly here. Apologies if I have, not my intention at all.
I have thought about something very similar to what you have explained, but with the experience of my own setup, reluctance has overwhelmed me to try it myself.
The factor I am trying to express is the size of the patch required to allow your control.
If I have it right, 15 pots connected to Axo analog inputs, 5 momentary buttons connected to digital inputs to select the mode group of the pots.
20 connections, each requiring their own object to read the pins state, this isn’t too much for the Axo, until you need to multiply it out to give a total of 75 controls in a patch.
So in theory somewhere in you objects and or code, you will need 75 separate conditions to send and or receive your control data at the correct place.
It’s the code and or objects x 75 times that will chew up resources, well at least how I see it from my experience which I have been commenting on.
I am not an experienced coder, but I do get by and find way around what I need.
But if you have found a way of getting around this, would love to know how you achieve it.
ricard
#21
From time to time I've been working on a project to run the Axoloti software on an Audiothingies P6 (https://www.audiothingies.com/p6/) hardware. The reason for this was ultimately to experiment with synthesizer design without having to build a hardware interface, as all that is already done in the P6. More importantly, the MCU used in the P6 is almost the same as in the Axoloti.
All this is slow work-in-progress, but basically I have accomplished three major tasks:
a) Porting the Axoloti firmware to the P6 platform, and
b) Implementing Axoloti objects for handling the P6 hardware, most importantly the 2x24 character LCD display and the rotary encoders, as well as
c) A basic menu system centered around a few objects holding tables with various menus.
The point of the exercise is to be able to emulate the P6 UI in a fairly simple way in the Axoloti environment.
Now, a), will probably not be very useful to most people, especially since Audiothingies ceased production of the P6, but b) and c) would be useful in other contexts as well.
The P6 uses 74HC165 and 74HC595 chips to essentially handle all digital I/O using a simple serial protocol - basically a clock line and a data line, which reads data from the latched shift registers in the 74HC165 chips or sends data to the shift registers in the 74HC595 chips which are then latched to the relevant outputs.
Unfortunately, I have not gotten around to uploading any of this to the contrib section mainly because it's been work-in-progress and I've only recently acheived something which I would consider useful.
A side note here is the UI concept used in the P6. Basically, there is a 2x24 character LCD display, which at any one time can display (up to) 6 parameters. Underneath the display there are 6 knobs which control the 6 parameters displayed. The top line displays a parameter name (abbreviated, as there are only 4 character positions available for each parameter, which in practice ends up as 3 characters, as you'll need a space between the parameter names for readability), and the bottom line displays the actual parameter. The buttons on the panel select a menu page, and for the P6 firmware this is cunningly laid out so that each 'module' (i.e. oscillator, filter, etc) occupies a single 'page' of 6 parameters.
The whole idea is that it's not a deep menu based system, you basically press the OSC button which brings up the parameters for oscillator 1, pressing OSC again brings up the parameters for oscillator 2, etc. So it's much easier and direct to work with than a menu based system where you have to navigate to some menu somewhere and then change a single parameter, go to another menu to change another parameter, etc. For me this is the ultimate compromise between having a full panel of pots/encoders with dedicated displays/led rings, and a 'letterbox' type menu system where you select a parameter with one knob and change its value with another.
MC_DETH
#22
This is a different patch, but giving me the same problem. Solution was to adjust the settings for the MCP 23S17
