Next-gen and mini Axoloti hardware discussion

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

#122

:sleepy:
but >MEEOUW< I did quite some objects that try to make sampling FUN!
for example:

but I'm a bit lazy recently about documenting them, and some of them are new.
check out:
* rbrt/smplr allows recording a lot of slices after each other to RAM,up to 127.
eventually, once you want to delete some of these slices, this will result in fragmented RAM,
thus, there's a defragmentation-fuction implemented
* rbrt/lpr is for recording a fixed number of samples (1,2,4,8,16...) into equal-length 'slots',
which is conceptually a waste of RAM
* rbrt/sdrive is really worth looking at,it's a re-write of rbrt/ldrive, but allows pitching the sample up/down
64 half-notes.

Actually, this is a good to-do-list to get my contributions 'straight' , since they are a bit messy right now.
I will do a release-post once I got something done...

what I find to be very important is to get a buffered loading/saving to SD-card done properly,
and streaming as well.
this really has to be intergrated in the firmware,it's a big showstopper at
the time being that axo 'locks up' when you try to load/save a lot of data to SD.

cheers
robert

#123

@weasel79 emphasized the SDCard load/save/streaming locking issue as well. It's a high priority item for me to get fixed in an upcoming firmware release.

#124

But Robert, my fine Sampler-Object-Making friend, I'll have you know that yours is the first contribution thread I think of when it comes to sampler objects. They're obviously fantastic but without documentation or the upload of a demonstration patch, I like many others will struggle. I've often thought the best thing a contributor can do is to upload a patch, one where every connection has something attached to it. That way there is likely no need for documentation because the users can work it out by looking at the demonstration patch.

Thanks for the heads-up on what you have in the works, there's a whole heap of stuff I'm dying to try as soon as I can, and what you mentioned is definitely among them :stuck_out_tongue_winking_eye:

@urklang, good to hear about the streaming fix you have planned, and my apologies for unintentionally hijacking your thread with sample talk, and it seems that I have when I read it back!

Still, had to say something to put it out there and I'm glad I did.

#125

as axoman said, these are absolute gems and i just wanna use this opportunity to point at one of our biggest issue on the consumer side: the organisation/accessibility/documentation of the contributor objects.
there is sooo much ggood and even low level stuff in the library that is just very hard to find, because of the object browser, and then a lot of those are missing documentation/examples. so i think to fix this we need two things: first, a better object browser/organisation structure, and then second: more community involvement to make those missing example files/documentation.

just some more examples of stuff i use and only found super late by randomly stumbling over it in the forums: max11300 support, 74HCXXX support, i2c OLED drivers, etc etc not even mentioning all the useful utility objects.

#126

Nice idea to have a mini Axoloti.

A few notes/questions:
- In your teaser I see many wires around the analog TRS connections, which could add noise in the signal. Did you talk with Johannes about the pcb design choices and issues he had in the development versions?
- micro usb for the host port feels a bit clumsy.
- Will your PCB design be open hardware? With availability depending on one person I really like the idea that anyone can make some PCB's. In that sense the LQFP chips are a big benefit also, as they can be soldered by hand.

#127

  • The concern about the layout traces is a little bit vague, but I agree with the overall sentiment. Inevitably in a mixed signal board analog and digital components and traces need to coexist in a non-destructive way. There are various techniques for fighting against noise many of which I routinely use in my designs. It's not necessarily going to be obvious from a rendering where these are applied or what components/pins/traces are analog or digital. Noise performance comes from many factors in an overall design. Also, Johannes is not involved in the project as of yet.

  • I'm echoing the Raspberry Pi Zero here, and yeah, it's a bit of a compromise. It will be possible to break out to a full connector via test points if you want to. The really important thing we need to do here is get hub support released. If only a single device works, both connectors are falling short.

  • My approach will be exactly like the existing Axoloti hardware: schematics and enough layout information to get work done and make expansions but not complete manufacturing assets.