Next-gen and mini Axoloti hardware discussion

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

#117

By making an offset to the write and the read object

By using math, you create a slice grid, but keep slices, in power of 2, 4, 8, 16, 32, 64 slices, etc. And do it in the s-rate. If the table is 2048 samples long and you want 16 slices, you divide 2048 with 16 and you get the size of each of the 16 slices and then you use that number for for example setting the speed of the phasor that reads the slices.

Using a phsor, with all the code in s-rate. Don't put reset functions in k-rate, but in s-rate.

You make an offset for the phasor, the same way as you do the read/right position.
When you make the slice grid mentioned above, you adjust the speed and the range of the phaser according to the slice grid. You divide or multiply the phasor speed that you calcualted for the whole table, with the amount of slices that you want, to get the speed for the individual slices.

That I don't know, but its really not something I would use.

You can use @rbrts excellent table copy object, tcopy, to copy a part of a table/sample to another table and then save the content of that table to sd-card.

The thing with Axoloti and all this timing and sample precision stuff is that it does get complicated, because of all the bit shifting. You can not use real world units like sample and hertz and so on, because of the bit shifting.

If you really want to learn and understand this stuff the best way to do that would probably be making it in Pure Data first, where you can do everything in samples, hertz and so on, its much easier to understand. And then when you know what you are doing, then build it in Axoloti, with all the bit shifting. But doing these things straight in Axoloti without understanding all the bit shifting, is really hard, I agree. But in reality it is really not that complicated once that you know the basic math, but it does take time to understand it and then build it.

Personally I dont use a lot of other peoples objects, because I don't understand what is going on. If one want to expand objects it is for me personally much better just start building it myself and learn on my own cause then I understand what is going on. Before I got Axoloti I had never written a line of code myself, but if one wants specialised tools, the only way to get precisely what you want, is to build your own personal tools and for that one needs to learn how to code.

And then we are back to the point again I was trying to point out. Good stuff rarely comes easy and takes a lot of effort and sometimes its good to learn coding and just dig in, to get where you want to be.

I read about the full duplex stuff a while ago in here, but I am not sure what it really would do or how it works, so I can't comment on that.

Anyway, yes, lets cut it here, and not take over this thread with sample talk. But pretty much everything you mentioned can be build with some effort.

#118

@urklang, It's the proverbial double-edged sword thing; damned if you do, damned if you don't :yum:

BTW, as we're talking about next-gen hardware, please, if possible, also make the patching environment truly next-gen by giving us a spectrum analyser. I don't mean as an object, I mean as something that perhaps sits along the top of the patcher screen somewhere, so that we could add a very basic object to the schematic, an object that has no display itself, but rather just an input inlet which is where the spectrum gets it's signal from.

If no spectrum object is placed into the sketch, then the spectrum takes it input directly at the audio out by default, and if one is used, it is auto-removed by the patcher before uploading to the Axo.

@jaffasplaffa, I understand your take on this and what you say is good for encouragement, but those answers assume people coming to Axoloti would understand all that stuff, and fact is, most don't. You see it often, people selling their Axo either on here or on ebay. There really is no reason a person would want to sell an Axo if they knew how to use it, and they would know how to use it if only the high-level objects were more capable, and much higher-level.

Having super-optimized high-level objects takes nothing whatsoever away from the more advanced users ability to continue using the low-level stuff. But what it does do is empower the rest; those who thought they were going to build something with Axoloti, to actually succeed in doing so.

Funny thing is, even those who think they would never use, say, a dedicated high-level sampling object, are completely and utterly kidding themselves. Technically, they would be using-up more RAM to reinvent the wheel if they didn't.

I personally always pay close attention to the objects Remco puts out, cause I noticed long ago that he totally gets the need for objects that are centric to specific tasks, where it makes more sense to bundle them together, do task-specific grunt-work behind the scenes, therefore saving RAM and ending-up with something task specific rather than object specific.

It's kinda like LEGO; when people buy LEGO, they know the only prerequisites there are to building whatever they want, is knowing how to push two bricks together and having the right sort of bricks. But while Axoloti has plenty of tiny bricks (the low-level stuff it does so well), it sadly lacks the right bricks that are essential to the sort of people who are going to be attracted to Axoloti for its 'Connect-up the bricks and off you go!' sort of thing.

#119

Yeah I agree, Axoloti is not easy. But when one starts to get it, it is really rewarding and it feels good to build what one wants :slight_smile:

In the beginning I had so many ideas and didn't know any coding and relied on people to help me with almost everything. Eventually I realised only way to get what I want, was to learn to do it myself. Now I have to ask only once in a while, which is a good feeling :slight_smile:

Sometimes I do need help, but the most I figure out on my own. But it has taken some years of learning c++, dsp programming and so on. But the really math heavy stuff, like FFT processing and stuff like that I understand absolutely nothing of.

Yes true, having high level objects doesn't take anything away from the low level stuff, that is true. But I think in general for complicated stuff, it is better to make subpatches, based on smaller objects. Making really complicated objects and make it all in one object, quickly gets hard to understand. It's easier to keep the individual processes separated and combine them in a subpatch. Like LEGO as you mention.

But yeah, let's see how it goes with this next-gen Axo project. I look forward to see how much upgraded it is going to be, memory cpu and so on. This will expand Axolotis sampling capabilities a lot :slight_smile:

#120

I am not sure I am a fan of that, cause it will take resources away form patching. It has to be optional, so one can choose if they want to spend those resources or not.

#121

Totally agree it would need the ability to be disabled, especially if it's a resource-hog. Totally would love to have one though.