Hardware interface concept question

#1

Hi Guys,

I am presently muzing about what my personal ideal hardware interface would look like.

Is it possible to use the hardware interface in a sort of menu driven configuration? For instance by connecting the 5 digital inputs with switches and use them to reconfigure the functions of all 15 analog inputs at once?

So what I want to do is build a sort of generic interface that I can use to control 5 seperate groups. For instance for a LFO section, an oscillator section, a filter section, an amp section and an effects section.

I know this sounds a bit like going back to the "good old days" of menu driven digital synths but if this can be done one would for instance be able to configure 15 analog inputs to control 5 x 15 = 75 parameters when just using the 5 digital inputs to scan for simple selection bits. So in the above example I would go to the LFO section if I press switch 1 and go to the filter section when I press switch 3.

Or can such things only be done with a MIDI controller using a dedicated MIDI controller number per function?

Marc Brassé

An alternative take on making an enclosure
The Holy Grail ? (second reprise)
#2

you can easily setup the 5 x 15 control with a multiplexing system, you may even want to do it backwards, 15 x 5, but for the analog side, if you want to use pots, raises the challenge of storing the value every time you change group, and a way to re-apply the value when you next re-enter the group. Reason being, every time you change group, the current pot value will be read, and I would expect you don't what that value to apply, or do you ?
Then there is tyhe challenge of deciding how you want to control the value when the pot value and the stored value don't match. There has been small thoughts on other posts to set it up, so the the velue does not change until the pot and the stored value match, this wouldn't too hard I guess, but you also may want some sought of an indicator to tell you when you have reasched the matching value.:grinning:

#3

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.

#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! :sob:

"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!:sweat:

Marc

#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. :slight_smile:

Marc

#6

@Rbrt has an object called tablestore that could do the job:

Bildschirmfoto 2017-10-30 um 00.15.35.png1038x658 35.5 KB

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.

#7

:thinking:

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.

#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.

#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

#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.

#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.

#12

Hi guys,

Great to see you become so enthousiastic so quickly.:grin:

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.:disappointed:

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.:smiling_imp:

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

#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

#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.:grinning:

#15

@MC_DETH, I have never seen the behavior you describe.
Have you checked how its all connected ?

#16

:thinking:

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

#17

I suspect its a hardware issue, going to look into it later this week.

#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. :yum:

#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.

#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.:grin: