Next-gen and mini Axoloti hardware discussion

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

#102

Just confirmed a slightly weird thing about the original core: if you inject a differential signal into LIN+ and LIN- etc what you get out of the TRS output is inverted. The TRS line in inverts into the codec and then the codec output is inverted into the line out stage, so TRS to TRS is properly in phase (the codec itself is configured to be noninverting). What I'm noticing though is that this probably means (I haven't measured it yet) that the headphone output is inverted with respect to a line in signal because the line in is explicitly inverted and then never inverted again for headphone output.

Anyway it's probably not a hugely noticeable thing, but we might as well have all the IO be in phase as much as possible unless there is a technical reason not to, and I'm not seeing a reason not to. Has anyone else noticed this issue?

The new core has a workaround for this by the way, i.e. so line in and out, differential in and out and headphone output are in phase by default.

Anyone selling their unused core?
#103

I would say that there is a bit of dc in the headphone minijack as I discovered when I plugged Axo into my oscilloscope.. Not a super bad thing but anyway I'm happy that Axoloti has dc coupled outputs and I can drive lasers with it or send modular signals if I want..

#104

@servandisco This sounds completely normal. The headphone output is driven by a special "capless" headphone driver that is part of the codec. The output signals are relative to a virtual ground that it creates on one of its outputs. In other words, it's expected that it might not appear to be centered at zero if you just took a normal measurement relative to one of the normal grounds elsewhere.

#105

that is what i was trying to say in the other thread post for post. he wouldn't believe :slight_smile:

#106

Quick question for those that have 2+ cores on hand: how does the current patcher handle it if they're both plugged in? Does it do something reasonable? Do you usually just patch one core at a time? I only have one original core on hand right now so I can't test this easily.

#107

Came up with this interesting IO idea for the new hardware based on a discussion with @AndrewChi:

io_idea1.png3130x1589 256 KB

Having four assignable TRS jacks will let us do some interesting stuff like this. More details to come about the latest improvements to the design, but in short, by default the IO will work exactly like the current core: headphone out, stereo line out, stereo line in but with an additional aux in that can be mixed into the normal stereo ADC. Each jack can be switched into a mono balanced mode that directly uses the codec hardware resources rather than doing any explicit inversion/balancing at the DSP level.

Overall board size will remain roughly <= 100mm in length, but we're switching to proper threaded through hole 3.5mm jacks that can be more easily faceplate mounted. I'm planning to make the board available without the TRS jacks populated as well so you can easily add the ones you prefer or use future breakout boards.

I want to make a shout out to @weasel79 and @JoshuaACNewman as well for their insight and support.

#108

it is basically one patcher per board, so you open up one patcher, connect one axoloti, open up the next patcher, connect to the 2nd axoloti

#109

If both cores are connected, no patchers are open and then you open a single patcher, does it just pick the first connected core that it sees? Or is there a configuration setting somewhere that helps remember which one is which?

#110

i think it just connects to the first one it sees. but i will have to check

#111

I dont understand the talk about lack of sampling objects here.

Everything is there that you need to build a perfect sampler, you just have to work for it.

All though I would like a cubic interpolated table, but still, what we have is pretty great as is.

Like everything else with Axoloti, the good stuff doesn't come easy. That is a pretty general thing, good stuff rarely comes easy anywhere in life.

#112

While you aren't connected to the board, in the menu "board" there is an option to "select device". there you can assign names to your different Axolotis and then choose which one to connect to. In macos, by default, Just one at a time but you can also use the terminal to open another Axo instance and edit 2 Axos at the same time.

#113

As a "learn to code project" for OSX I made this app that opens terminal and launches the Axoloti app automatically. You can open as many as you want using this app.

For the renaming Axoloti cores, you can do that in OSX audio/midi settings. You can rename any OSX usb device there. Its pretty nice to keep it organised when working with multiple Axolotis.

#114

Awesome! I should try to do an Axoloti quartett, now that I have a multichannel soundcard too :slight_smile:

#115

@jaffasplaffa, it's because the sample objects are far too low level as they are, and efficient full-duplex objects are non-existent as far as I'm aware. There is no way the layman coming to Axoloti is going to knock-out a proper sampler or a multitrack recorder with it.

It's very cool, and of course essential, that the low-level objects are there, but that doesn't mean the higher-level objects should be excused for how limited they are. It's not about having to work for it, and Im guessing that even you would not be capable of putting together an Axo patch that demonstrates how to build a full-duplex capable multitrack or a proper sampler.

A proper sampler is a bit more than recording the input and triggering the sample to play it back:

  • How do you access the read/write position of the sample?
  • How do slice the sample at sample-accurate positions?
  • How do you even play a sample from a sample-accurate position?
  • How do you select portions of a sample?
  • How do you cut/paste/discard sample-accurate portions of a sample?
  • How do you save a specific portion of a sample to an SD card?

They're just some examples of why the high-level stuff is simply not high enough. I'd be very surprised if you yourself would be able to build such a sampler in Axoloti. The amount of low-level objects you'd need would likely eat up so much RAM that even if you managed to work it out, there would be no room for it. Which actually, brings me to something I've wanted to point out quite a few times now and it is this ...

There is often talk about how adding more features to an object increases the amount of RAM it requires, and while that is obviously true, what also needs to be be considered is the fact that bundling purpose-made facilities into one big abject can also save RAM, not waste it. A more sophisticated sampling object that contains what is needed for a 'proper' sampler, would enable you to do, in much less RAM, something that would otherwise either be impossibe or an outright nightmare to do if you were to do it all with the low-level objects we currently have.

Despite the very obvious interest among Axoloti users for sampling/recording based stuff, not a not a single person has uploaded a sketch that demonstrated the abilities in that list I just gave you, and the reason for that is because even the highly-skilled among you have not managed to create such a thing. This is why sampling needs it's very own super-optimized object that takes care of all that stuff internally, therefore saving the need for masses and masses of low-level objects, and as a result actually allowing the layman to build what they thought they were going to be able to build.

Same with full-duplex, there needs to be dedicated super-optimised objects for that, but there aren't any.

So it's not about working for it, but if you honestly think that, feel free to upload a sketch that demonstrates how to wire-up the current objects in order to achieve those sampling essentials pointed out in the list.

I say good luck with that, but if you do manage it, please start a new thread about it because I assure you it will prove very popular indeed and it would otherwise hijack this thread and that was not the intention. In a nutshell, a much higher-level super-optimised object that specialises in sampling/recording is needed, and another for super-optimised full-duplex.

#116

Love this analysis. I want to emphasize one thing. A lot of these problems have been solved in other pieces of open source software. Think of all the GPL software lying around that can handle digital audio in sophisticated ways: Ardour, SuperCollider, PureData, LinuxSampler, VCVRack, etc.

Axoloti's codebase has a pretty strong tradition of handwritten stuff. I think we need to move toward a culture of compatibility and code reuse. Yes, we're targeting an embedded system, but that doesn't mean we can't start with some hardened desktop code from SuperCollider or VCVRack and optimize it. We're never going to be able to keep up if can't reuse DSP code from external sources easily.