Next-gen and mini Axoloti hardware discussion

#82

Wow, been reading this for some time and it sounds great. Would buy several ...

#83

@urklang, your work on this is phenomenal.. ! :star_struck: Demand will be there for sure..
Just putting it out there, hypothetically, would there be an opportunity with the faster processor to handle more audio input / output with a future breakout ?

#84

@Gavin I think this is definitely a possibility. The H7 has various hardware enhancements other than just the raw clock rate as well. It has FOUR serial audio interfaces instead of the original one on the 427. Check out the side by side:
427 (current processor)

427.PNG963x461 91.8 KB

H7 (new processor)

h7.PNG1179x768 75.3 KB

We'll go for compatibility first and then we'll try to unlock some of these new bits of hardware over time for new features and breakouts, etc. I'd like to see some kind of multichannel audio solution and also a multichannel CV breakout.

#85

and moar MIDI Outs, please!

#86

I think it's a good idea and 10 pin should be enough (even five since the connector is redundant) if you are converting to 5v in the board. the cv and gate pins are there in the Eurorack specification but not many modules use that (even from doepfer)

Also, many power supplies don't provide the 5v

#87

i think any needs for more midi outs should be covered by external hardware, ie. a midi splitter and using unique midi channel. adding several dedicated midi out pins on the axoloti board would clutter the pinouts. you could also always hack this up by using some of the serial TX/RX pairs and doin your own midi out.

as you can see from the specs @urklang posted there are plenty of serial I/O options which should all be poosible to be use with future firmware/software updates.

as for eurorack CV out shields/breakouts, we are discussing the max11300 and also investiggating other options, hopefully to have a somewhat standartized CV breakout module ready close to the availability date of the mini axox board

#88

agree with 1 midi out, midi splitters are cheap and probably not everybody / not even most Axo users are dealing with several synths that don't have midi thru.

#89

Thanks for the support everyone! It's really inspiring thinking about all these possibilities.

I want to see the development process become more responsive to the community over time, more transparent. I'm thinking of something like this: we have a public queue of new features and enhancements, hardware and software. Whatever is the highest priority item is simply the one that is most funded/upvoted by the community.

By the way: now is the time to post any hardware issues you are aware of with the original core. I'm looking for specific, repeatable ways of producing problems, like noise or failure, etc. This shouldn't be a feature request. It should be something like:
1. I plugged this in and then this.
2. I heard buzzing or something weird happened or I fried something, etc.

It should be clear that it's a hardware specific problem. If it can be resolved in software, we're fine and we'll take care of that later. We ideally want to get the hardware exactly right on the first prototype run. Also, it should be specific to core itself not external hardware you were attaching although if it's a situation you think could be avoided with additional protections, post it.

If you give me issues I can reproduce on my original core, I'll try to debug and resolve them in the new design.

#90

Not exactly sure of the technical reason, or even whether it is down to the software or hardware aspect of Axoloti, but there are two very obvious and frustrating limitations with the current Axo system:

1 - I think the design of the hardware suggests that sampling and recording-focused projects were not given as much credibility as, say, analogue modeling synths etc, during it's design. What might surprise you though, is that it is always sample-based sketches, objects etc that generate the most interest from users of this forum. Whether it's just an object for looping or something more elaborate it is always the sample-based stuff that generates the most interest.

This does not surprise me in the least, because it shows that the sample-based oblects are far too low-level for most users, and that much more thought needs to be put into their design and abilities. For example, a layman coming to Axoloti is going to expect a sample-based object to contain connections that access start point, end point, current position read/write, loop mode, and reverse, and for all the 'tech stuff' to be dealt with by the object itself as opposed to masses of external objects and complexity eating-up RAM and complicating things.

2 - Same goes for recording and playing back audio as a multi-track recorder would. I would love, for example, to create a very basic no-thrills digital multi-track recorder, but with the current Axo, no chance, not unless I was some low-level code guru. The current Axo lacks the RAM to build a comfortable system, and it lacks optimised full-duplex recording/playback objects.

These are both very obvious shortcomings for a digital audio system designed to allow the consumeer to build what they need. It is especially frustrating because the hardware has both audio ins and audio outs.

Like I said, I suspect that sample and recording based stuff was not what Johannes had in mind, I think he was thinking more along the lines of analogue modeling and other more experimental stuff.

So in a nutshell, what I'm saying is that those two areas absolutely need to improve, and as Johannes is currently pre-occupied with the live system he's working on, maybe you will give the matter some thought for the version you are working on.

#91

@axoman Great points. I don't think technical or hardware limitations are a credible explanation for this shortcoming. It's a design and usability problem. The obvious use cases with sampling and digital audio need to just work and be as intuitive as possible to non-technical users. This will be an area of focus for me when I'm preparing the software distribution for the new hardware. Initially, I'm not going to take things on that aren't obviously low hanging fruit though. I don't want to delay getting the new hardware out. Once it's out we'll be able to focus on getting to the root causes of some of these obvious usability problems.

#92

Regarding hardware issues with the current axoloti: the L and R input channels bleed into each other a tiny bit. Not sure how this comes about, but it happens on both of my axoloti cores - I haven't tested it extensively though, could also be a symptom of the TSR jack or cables on my side. Either way I have never been able to 100% split L and R inputs.

#93

Good to hear, and personally I'm most interested to see what changes you make regards the amount of RAM because I'm under the impression it will effect the amount of buffering etc that can be handled when dealing with recording/playback full-duplex etc.

It could mean the difference between 8-track playback and 32-track!

Either way, it's a relief to read your reply, it's definitely an area that needs big-time improvement. I bumped a thread for you yesterday, but that was before I read your reply. Nevertheless it shows how starved the layman is, and where the current Axo system can be improved in that area.

#94

hey i agree with what you said here and in the other thread @axoman the whole sample playingg side has been pretty neglected and lacks some more convenient real-world usable objects.

that being said, of course we would benefit from more ram but i think the problem you describe moreso lies in the lack of simple dedicated objects and a good library system/documentation for those. you see, that thingg @lokki made in the other thread, a simple sample scrubber, should be an obvious and immediately "findable" part of the library by now. just like some issuea i had w drivers for the max11300 and 74HCXXXX chips, all that stuff is already in there somehow but it's really hard to find, either by randomly stumbling over it in the forum or, well no or, because the current object browser in the patcher is just outright terrible.

so yeah. we need much more of that, and much better organized. who is willing to put in some work on that? maybe to start with even just gathering a list of "important" musicians/consumer objects that either don't exist or are hard to find due to reasons described above?

#95

what about patch editor? i.e. if i want to use both old and new boards (with same patches?), do i need few different editors on my system? what about hardware-specific blocks used in patch like audio outputs, gpio's or adc's?

#96

a first version should be a drop in replacement, as has been stated by @urklang

#97

Bracki (on discord) and I are discussing plans for a sort of universal patcher that will drive both versions of the core and my Zrna analog board. The long term vision is to have a single patcher app.

The first released version of the new core hardware will be driven by a version of the legacy patcher. I expect it to be backwards compatible with the existing core hardware unless there is a very good reason. So basically you will download the new software distribution and be able to use it with both new and old cores.

Objects that depend on physical pin layout should be directly compatible because the new CPU is pin compatible and uses all the same pin assignments. If there are edge case situations where this isn't the case out of the box, we'll fix it in software so that the correct physical pin is used for an object depending on which core is in use. Again, I don't expect this to happen much. We may run into this kind of thing more often as we start to use the more advanced hardware features on the new H7 processor. Basically the patcher will be aware of which one is connected and handle available features accordingly.

#98

@weasel79, I wish I could help, but I'm not a coder, but yup, I'm with you on the need for a better search system. The problem is, in order for a search system of the type we need to be effective, contributors would need to start tagging, and I doubt many would respect that. So the best search system in the world could be developed, but it would still fail unless there was a way to force correct tagging of the objects being uploaded to the library.

@urklang, It sounds like you're going to eventually have the patcher control both the Axoloti and your FPAA board in the same patch, and that would be absolutely incredible if that's the case. Makes me wonder how it would work when Johannes gets the live thing sorted though, unless you intend for your version to not use the live system.

#99

@axoman Exactly. It really depends on what Johannes' take on a live system actually does if it's released. I think it's unlikely that I will reuse it exactly because I think we need some more fundamental architecture changes to get to the universal live patcher idea. Johannes hasn't given any specifics on his approach so it's hard to anticipate how it will fit into what I'm doing.

Several of us on discord are in the process of sketching out a more universal hardware <-> patcher architecture that will give us live patching and be more flexible for future pieces of hardware. Adapting all of the existing patcher for that is probably unrealistic; a lot of it will be rewritten.

#100

It's a shame you and Johannes don't live around the corner from one another, otherwise you could have indulged in some serious midnight-oil-burning collaberative coding sessions :owl::owl:

#101

@weasel79 and Bracki and I are trying to lay the foundation for a more inclusive and logical development process going forward. I'm just one guy; it's going to be hard for me to do all the hardware and software work on all these projects myself. We need to do everything we can to make it easier for people to contribute. As an example, someone who is highly motivated with user interface stuff should be able to upgrade the patcher UI rapidly without needing to know a lot about hardware and firmware details.

Because the Zrna board is still more of an engineering style product right now being API-driven, the early users tend to have some programming chops. I think there are Zrna users who might not yet know about Axoloti/Akso and will likely be interested in both devices, so we might be able to get some developer interest coming in from the Zrna side.