Next-gen and mini Axoloti hardware discussion

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

I don't know if it is even possible. But one thing that I would like to see is either a breakout board or an port on the core that are of AVB protocol (Audio Video Bridge, open standard AFAIK).

If I've understood the AVB concept correctly. Any device/brand utilizing AVB are supposedly compatible with each other.

(https://blog.biamp.com/open-avb/)

For example, MOTU have a lot of products in their AVB series. Which means that you can expand I/O connections as well as having a audio network (allowing long distance audio signals that are still in sync). An DIY board hi-jacking into such a system would be really neat.

#129

seems like an interesting standard, but i've yet to see a lot of companies supporting it? are there any low cost/diy world modules/codecs available that support it?

here's a thesis from someone making it work on a beagle board, but thats linux w ethernet built in.


and i saw some google results for ARM implementation too...

i think i2s might be easier to implement first because all the other STM32 platforms have libraries for it already. and it will have a decent amount of hardware support/choices. but after that, sure, i am down to see what other digital i/os make the most sense between AVB, spdif, MADI, ADAT... not even sure how far i2s can go for mutichannel stuff.

#130

@weasel79

Just curious here, as you seem to have some knowledge:

  • Are you a programmer by trade?
#131

I2S and AVB are two very different solutions to two very different problems.

#132

i just have a talent to gather the right keywords quickly and throw them around in a way that makes it look like i know what they mean. if (coding_skill < 0) then DOES NOT COMPUTE.

  • i make music by trade
#133

as i just said i have no clue on a low-level-level, but both do support digital clocked multichannel audio, don't they? avb on ethernet, i2s on a couple serial pins. both are open standards. avb might have a lot of video overhead?
and from what i've seen, stand to be corrected, there are more codec modules/interfces to be had for i2s currently?
edit. apparently other than motu presonus and RME also have a couple interfaces with AVB support. so that covers almost the whole price range, other than low budget module stuff which i2s has.
but AVB would mean we need full ethernet support so i maybe that's a figght for another day...

#135

AVB is a networking technology, for distributing time-sensitive data, like audio and video, among multiple devices.

I2S is a simple serial protocol for transferring audio data between two devices, typically over very short distances.

@miketheman brought up AVB, but we don’t know what he had in mind besides interoperability with multiport audio interfaces.

For this, I2S isn’t appropriate.

#136

Let's think about this another way: as far as I know we have no practical way of exchanging real-time digital audio between Axoloti devices. As a first step, we just want to make this possible, using the simplest implementation we can. I2S is probably what we want to get started. We don't want something that implies having a whole networking stack.

We need to just get something working first so we can evaluate a practical implementation. If performance is inadequate, we'll evaluate alternative protocols and optimizations, etc.

#137

Does this proposed I2S link between Axoloti devices depend on H7 features, or is it theoretically possible on the F427?

#138

I suspect that we can make it work on the F427 as well. From the datasheet:

427.png1292x243 31.3 KB

The internal codec uses the SAI.

#139

I just made an order for prototype hardware. The turnaround time is about two weeks. If everything looks good with the prototype, I'll open it up for production run orders.

#140

Thanks for clearing the differencies up. Not sure that I could have explained it in a simple way.

There are some brands supporting AVB, for private customers mainly audio interface and/or mixers. I've yet to see someone combine two or more units of different brands. Heck I'm not even sure I've seen/read of any end-user combining two of the same brand. Then again, AVB were AFAIK developed with time sensitive signals (audio/video) over network in mind. If it works as supposed then there might not be as much to say about that function.

Cool thing with MOTU AVB is that they have an web server integrated. So you can use them stand alone (without computer) as a stage mixer and still adjust i e levels via cellphone that you connect as a client.
I've been looking for a personal monitor system that is possible to expand I/O (me and my band would love to incorporate synths/drummachines) and more specifically gives possibilities to route a selection of channels from/to each member where it's possible to adjust levels locally for each member.

When I worked at Elektron (production) I tried to get R&D department to look into AVB. The response were "nah.. we don't know maybe sometime in the future?". Still they developed and have integrated audio interfaces in many of their products today. A missed opportunity in my humble opinion.

I realize that it requests resources, but we were talking next-gen ideas? I am imagining that AVB would/could push the implementation of connecting several core boards into one patcher as well.

#141

First things first. I agree. If I had the resources/knowledge I would definitely look into it myself...

#142

i remember johannes posting in some i2s/digital audio thread that the i2s options of the chip were not pinned out in the current xxo design? will try find a source..