from my point of view, vertical environments (pd/ max / cablesGL / vvvv) have certain advantage for doing logic stuff, gates, routing, sequencing, math stuff but then Horizontal environments (Axoloti, Isadora, Nord Modular, VCV ...) have the advantage that the objects are easier to see / understand, quicker and sometimes nicer too but they usually take more space..
I always wondered if it would be possible to combine paradigms in order to have the best of both worlds.. From small objects like [* ˜ ] [< ] to bigger abstractions like many Axoloti / vcv Macros, / synths / stomps etc where it's clear and easy to understand what every input / output does, etc.
Also one thing that I always wished it was different in Axoloti is the ability to connect different signals into the same input without the need of using a Mux.. That would save lots of space and time.. And also the Send & receive thing, that they could be instantiated many times and also between subpatch and mother patch..
Just throwing some ideas.. In case any of them makes sense to more people. 
Next-gen and mini Axoloti hardware discussion
If in this interface you could place the patchpoints anywhere (sides & up/down) . make the patchpoints smaller and with the possibility to add a label to them & also being able to redimen the knobs, that would be already a super nice way to do interfaces for macro objects. Anyway, It looks quite cool
Maybe port orientation could be dynamic per object, i.e. you could toggle between a vertical and horizontal orientation or perhaps other auto layout algorithms. I think having the option to hand optimize the layout of certain objects would help a lot with legibility too. I was reviewing the old Nord Mod objects recently and was surprised how well they hold up visually; it seems like each layout was hand designed. Nord feels more like Rack to me where inputs and outputs are sort of flexibly mixed on a panel to suit the particular object rather than having a strict vertical or horizontal orientation.
customized layout sounds awesome to me..
http://servando.teks.no/?serquencer/
That interface it's done in puredata, Although its not known to be the nicest, already allows for making quite personalized Gui's thanks to the usage of colored & resizable canvas, knobs, sliders, buttons and other gui elements, but definitely I would love to be able to have inlets and outlets also in the sides of the objects (or even inside anywhere, why not!.. )
For some of the sequencers, the layout for parameters is horisontal rather than vertical. For example "sel/sel i 16" sequencer object, than one as 16 parameter in horisontal direction.
I have never really found out why some objects lets you place them horisontal rather than vertically, but today I checked the XML code fan for the object. And at the top of the objects XML code fan, there is this line:
This line I am pretty sure lets you place the parameters in horisontal way rather than vertical. So to me it seems like there is already a basic implementation for placement of parameters.
So if the object editor would be updated so we can actually edit the XML code form the editor, it is really simple to change the placement directly from the editor. Or maybe just make an in editor button, that lets you change that statement from true to false. And maybe ven more options would be nice
I guess placement would not be 100% free, but it is a baby step
Update: the revised USB-C prototype has shipped from fab. I should have it in my lab in another day or so.
I’ve not really even following the discussion...
but the vcvrack idea is interesting, as I think customizable modules UI would be cool.
But, the vcvrack has no concept of sub-modules, which is a very big part of the axoloti UI ... I’d see it has being hard to graft that onto vcvrack ( esp. as embedded objects)
Also I’d echo @jaffasplaffa , vcvracks main issue appears to be cpu load due to graphics , I always got the feeling the performance on audio side was fine.
Also the other area I really appreciate on axoloti is the coming of objects in line in C++ , at times that’s been a bit like a live coding (and is set to be improved I think in 2.0)
Anyway interesting developments,
I’m sure if the axoloti client side was moved to c++ it would see a huge step in performance, but it’s no small task.
What’s the measurements of the new board?
I’d really love to squeeze one into an ae modular module /)
Definitely agree with your take on the VCV idea. It's conceptually different enough that it'll take some effort to get the full semantics of the old patcher there. What I've done so far is really just a basic proof of concept to get a sense of how it feels to work with the GLFW rendering engine in Rack, how we would draw Axo objects, etc.
In parallel I'm working on just being able to run the Rack DSP engine in the embedded environment. In the short term, I could see having a separate firmware stack that is purely for running Rack modules but then later on being able to interoperate with axo domain stuff.
The board was designed with module and expansion making in mind. It's roughly 100 x 40mm. I'll publish all the details before we go live accepting orders.
oh yeah minimalist interface
like there was a super important update in max/msp when they made the cables wiggle
now i'm scrolled more down i see that i'd say please do an option for straight cables
that's how i use most of the spaghetti programs maybe also lighter to draw
may some keybinding over the cabe or per selected cable could insert a mux module or other utility modules
I realise I've probably left it a bit late to mention this, but ...
I once asked Mark and Johannes about the possibility of having the board run at a bit-depth and sample-rate of the users choosing, something we could specify as a patcher setting so that it would upload to the board along with the patch, and configure the bit-depth and sample-rate.
The reason I asked about this is because it would be very nice to be able to sample in 8-Bit, and to have an entire patch run in 8-Bit. It was suggested to use various methods to simulate it, but the problem with that is it only increases the load required.
Considering that axoloti manages what it does at a sample rate of 48KHz, can you imagine how much it would be able to handle if it were truly running at a genuine rate of, say, 11.25KHz, and at a true bit depth of only 8-Bit?
Imagine the size of the patches we could make; we'd likely be able to knock-out a full-on 8-Bit workstation from an axoloti if it only needed to handle those bit-depths and sample-rates.
If I recall, Johannes said it was possible but would take a lot of effort, so unfortunately it's not on the todo list.
It's a shame really, cause of course it would permit the opposite too. A person might want to make a super-high-fidelity outboard effects processor that runs at 96KHz. So what I'm saying is, if at all possible, please build this ability into your version of the board - it would be really nice to be able to do stuff like that.
Love this idea. It's definitely on my list. Enabling 96 and 44.1 is easiest in the short term. Having arbitrary sample rates and bit depths for the whole engine would be so cool. It's definitely possible. How seemless it is and whether or not it could actually save resources depends on the implementation. I could see intentionally running at lower sample rates and depths for aesthetic reasons too.
Off the top of my head it may be easier to start with a base system that has all of this available and then port the legacy axo objects to it, rather than trying to graft it onto the legacy system.
On the subject of 8-bit and chiptune etc: most of those classic soundchips have solid GPL'd implementations. It's on my list to port over as many as possible. I also want to look at being able to play soundfonts, run a general midi synth voice, etc.
this has been discussed before (*) ... the main issue of running at different SR is due to quite a few existing objects (and bits in the firmware they use) assume a given SR (e.g tables) - so these would need to be altered to allow for different sample rates (and in a way that does not reduce performance in the 48k scenario).
not really that 'difficult' to do, but likely would take quite some effort to go thru all cases.
an example of this can also be seen in VCV rack when using MI modules.
MI modules are 'hardcoded' at a given sample rate, so VCV rack upsample/downsamples as appropriate from the computers SR to the required MI SR...
of course this is viable on a desktop, since they are much more powerful than the original hardware.
but its not really viable on more limited hardware (and why i don't do it on things like rPI/Organelle)
(*) usually in the context of generating code for other boards to run.
Have to say, that was quite an enthusiastic response and I was expecting the opposite to be honest 
This is really good to hear, and yup, would be very cool to have it! Another benefit of it, one I forgot to mention, is that even dropping from 48 to 44.1 could save the day for a lot of axo projects. I'm not joking, even I managed to max-out my axo just short of completing various patches on it, and every time it happened I thought to myself, man, if only I could drop the sample rate to 44.1, I reckon the board would have just enough DSP grunt to handle the completed patch.
Yup, just that little bit extra would'a and could'a done it, dammit!!!
Soon that DSP limit and ram issues are not going to be issues anymore, atleast not as we experience atm. When we get the new board, from what I understand we around 4 X the power on most aspects, like SRAM, SDRAM and so on.
Very true, Jaffa, but you can never have too much DSP, RAM etc. The new board will feel like absolute luxury at first, but once we start taking advantage of that luxury, before we know it we'll likely see comments like:
"So hey, when's the new, even bigger board coming out then, urklang?" 
By which time of course, Johannes might have completed his live system and be working on another version of the board that would in turn make urklang's board look primitive! This in turn could cause urklang to think, right, I gotta better that and offer an even bigger board!
One can dream, but nevertheless, I think it would be quite amusing and actually very beneficial to us all if we saw a friendly "Battle of the Boards" so to speak - hahaha
I'm sure we'll quickly find ways to put the extra headroom to good use! 
I want to be clear though: there's no reason to turn this into a competition. I think collaboration will benefit us all the most in the long run. I'd be the first to welcome Johannes back as a collaborator. What I care about most is pushing the technology forward!
Oh yes indeed, I made absolutely certain to include the word "friendly" in my comment as I meant it in a fun but productive way
Funny you should point that out though, cause just yesterday I was thinking how much more productive this could work out with two major devs working on their individual axos at the same time, we're being spoiled really, and I'm sure every one of us are super-grateful (I know I am). It allows Johannes for example to concentrate on getting the live system running silky-smooth, yet at the same time, you are working on stuff it would be impossible to do if only one of you were doing this. Eventually, who knows how you might collaborate to harmonise it all in the future, to bring it all together.
To be honest, I personally am more attracted to the fact that you agree with a lot of the stuff I mentioned. The extra power and RAM of your board is if course really welcome, but it's actually the thought of having some quality, easy-to-use, higher-level sampling and SD streaming full-duplex objects that attracts me the most. I feel confident that Johannes would address this eventually when he finds the time with his board, but the point is, it's nice to know there is another developer who agrees with it's shortcomings in that area and recognises the need, so you doing it might take some future load off' Johannes - who knows!
I'm not saying it specifically would, but you know what I mean, it's cool there is the potential for you to effectively lighten each others work load.
So I'll be watching you both closely, and as long as there is no fighting between you, axoman will not have to call-in da technobear
While I really shouldn't do this, the amount of likes on your previous post makes me feel I should apologise if my comment made it look as if I meant making a competition of it. I'm afraid the British sense of humour is misunderstood regardless of decades of the web facilitating worldwide access to it! To be fair, Ozzies seem to get it, though not all of them, but regardless, I do wish I lived in the land of Skippy myself.
Ah well, shut-up axoman. I'm still calling da Technobear if anyone gets out of hand though 