Hardware interface concept question

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

#22

This is a different patch, but giving me the same problem. Solution was to adjust the settings for the MCP 23S17

IMG_3543.JPG2794x1745 1.79 MB

#23

Dear Ricard,

Yep, that is basically the sort of thing I am thinking of. Too many pages and submenus do not make the expreience of programming very pleasurable/ practical. A matrix of 5 menu's with 20 prameters, would, as discussed, already be a killer. For even deeper programming one could still use the normal screen option of the PC-software.

I do however assume you are doing all data exchange via midi and my question concerns the possibilites to implement a similar solution using the Axoloti's own hardware input points, so to build hardware interface that does noto use midi for data exchange

But still, midi or not: Does the P6 in your case provide al lthe handling and tabling options (remembering the precvious contets of the sumenu'sand stuff) or does the Axoloti itself do that for you?

#24

Hi Gavin,

I fully understand what you mean. It is just that I cannot imagine that the data amount and thus the processing power needed will be that big, expecially when compared to other demands on the Axoloti, such as DSP.

Imagine a 75 line 2 column table in which every address is mentioned plus a single value for that address, the contents of the cells based on the users last visit to the accompanying object control input. O.K. that also might neccesitate the use of a 3rd column mentioning the number of the submenu but still; the rest of the processing would only be concerned with using the right value for the right object connection and updating the table every time a value is actually changed by the user.

But I am not a code writer either. At this moment I am actually getting to grips with the user interface. That's the disadvantage when you think (too?) far ahead. :blush:

#25

Hi @MC_DETH and @Blindsmyth,

You guys are probably already way ahead of us. Please explain in laymans terms as soon as you get close to a solution us amateurs would understand or at least be able to use.

#26

Hi yah all,

To get a more specific insight into why I am looking for the sort of solution discussed in thist thread you can visit The Holy Grail https://sebiik.github.io/community.axoloti.com.backup/t/the-holy-grail-second-reprise/2996/181

This is my first sketch of the sort of controller design I am aiming at:

Grailer One hardware interface V1.jpg2543x1230 463 KB

Marc

#27

@brasso speaking for myself here; I am an utter noob when it comes to sound synthesis (analogue or digital); axoloti; and diy hardware :slight_smile: I have been a noise artist for over ten years but it's only very recently that I became interested in crafting my own instrument and electronical music in particular. I am currently cutting my teeth on my first hardware build and progress has been slow, but I will post updates on how I get on with patching once I get going!

#28

We've all got our strenghts and weaknesses. I have seen all major developments in music technology of the last 40 years and worked with most synthesis methods out there. My weakness however is that I have untill now avoided working on homecomputers as much as possible. So I still have to work out the sort of basic stuff that will be totally obvious to the USB / Blue Tooth / Facebook generation.

So I am glad this community exist, even though some of you will probably think I am some sort of pre-digital dinosaur. :sauropod:

#29

Hey there,

my main experience in building interfaces lies with midi controllers. I built a little axoloti footpedal with knobs and leds stuff but all the wiring was killing me, never really got it to work.

So right now I mainly work with midi controllers thus. I would really advice against using analog inputs, as when you switch layer you don't know anymore where your values are and you got to figure out all of this take over etc stuff.

So your options in that case would be:
1 motorized faders
2 touch strips with led strip indicating the value (like on livid base)
3 encoder with led ring (like the encoders on akai apc40)

BUT all of these are pretty hard to DIY. So my advice is really look for a midi controller that has all the elements to realize your concept and go patching.

From the first look I think good old Behringer BCF or the newer X-touch compact seem to have all the elements you need.
The faders would be your envelope thing, the encoders your parameters and you can use the buttons to do all the switching you want
From what I know the BCF really had sophistacted possibiliets of custimozing the midi messages. For example you might be able to get something like rough and fine control that goes beyond the typical 0-127 out of the encoders, or use pitchbend on the faders if that is a concern.

Then eventually it is all just about clever multiplexing. You already got your concept, wich is good! So you only need to execute your plan in small steps. That is where having a hardware ready (like a midi controller) really helps from my experience!

#30

I actually think the on-board inputs are a mighty big advantage.

Since most digital systems nowadays work with a higher clock- / scanrates then MIDI they often react faster when processing their own interface inputs. On paper the difference might not seem that significant (what differnce makes a milliseconds) )but I a few instruments I own feel a lot vaguer when driven via MIDI then they do when played directly. Some of the direct man too machine interface experiences still get lost in those seemingly small MIDI latencies.

Furhtermore the on-board in- and outputs actually turn the Axoloti intot the nifty and unique solution it is. You can now really build your own personal hardware synth (with all them nice knobby thingies) without loosing the option to go extra deep via the screen.

Marc

#31

I do believe a lot of those "Midi Latency" issues you are referring to can be solved with Midi over USB, a lot faster. But obviously the downside is the Axo only has one port for that.. Wait a minute, that's right, they are working on a solution so that a USB hub can be used, yes that will fix it.. !! This is an upgrade I think can make a massive difference. There are many microcontrollers that can be used to make midi controllers over USB. :grin:

#32

I agree that USB midi is usually a lot faster the din!

Me persoannly I would also prefer to have an all in one hardware with the gpio but I realized that designing and building your own hardware interface is a very tedious process and that I actually want to make music with the axoloti. So with midi controllers I can realize my Ideas already, try things in the practical world and can then converge these Ideas into my own hardware (at some undefined point in the future)
So this was more meant to be an advice for starting somewhere and testing if and how your instrument concepts actually work in practice. I personally realized during this process that with some clever patching I can do it with less controlls than expected!

One thing to bear in mind is that Johannes is also working on a control board with 4 encoders and some buttons. This might be already your "Param" part.
Then you only need to add the "levels" and "times" control.

#33

OK. Interesting.

I must confess that everything I use until now is MIDI via Din. I just assumed that would mean the same speed for MIDI via USB bercause a maximum reading speed would be part of the MIDI-standard. Stiil, running everything via USB, so digital audio and MIDI etc., might again create latency. One would have to compare hard measurement data.

That @johannes is already working on some sort of additional interface is good news. That might indeed make the implementation of my idea's a lot easier as well.