Ksoloti Core

[Sebastian]

Oh that's good news, I am sure I can find the details in my forum backup (I am about to rewrite the documentation, install how-to, getting started etc.)

[poetaster]

Just a little eye candy. I'm still not quite finished with all the mapping, but that's also because I need to redo some layouts (physical ones). Here, a gif:



You may have noticed, the pots are all 'upside-down-side'. sigh. In my minimalist inclination I sometimes forget the inclination to the real

[ersatzplanet]

I have been using the patcher on MacOS since 2018 without any issue. Currently my Mac is on Sonoma (latest OS) and the patcher is running great.
There was a post on the forum explaining some extra steps for the installation for Catalina and later, but I can't remember the details...

I am guessing that if any problems arise, it is because of whatever version of Java is running on that particular OS. I have had to update Java in the past for some other programs that are a bit particular to what versions they use.

[Sebastian]

Anyone ever heard of the mysterious and elusive SPI-link?

Old legends have it that this feature would allow users to connect two Axolotis, let them enter a spiritual union and share audio and control data between each other.

"Why is this a big deal? I don't want to complicate things and could just connect them via physical audio jacks and MIDI, or no?", is what I thought. Only when some users shared their use cases for their Axolotis it became clear how big a deal this could be.

Need 4 audio IO instead of 2? Have a CPU hungry reverb you want to send/return audio to within your patch? Outsource it! This will in theory even give you two USB host ports so even the folks who were eager to get USB hub functionality may get some benefit in it.

Wonderful "proof-of-concept" code by Johannes that needed some head-wrapping-around, trial-and-error, bug-ironing-out, adjustments to Ksoloti hardware... Well okay, a bit more than that. Some headaches too. And sleepless nights.

The SPI is fast enough so I consider making it 6 channels duplex (currently 4). I created objects to optionally pack 16 parameters of control data into any of the channels.
(The original code had placeholders for packing up a lot of extra data like sharing MIDI and "Axoloti Control" data which is a mythical piece of hardware designed by Johannes mere mortals like us will never see, but I'd prefer keeping it simple and modular. As in, the synced Core should only receive the master Core's MIDI if you want it to: you can just pack it up and send it via a free channel.)

I currently am quite certain that it is possible to stack the two Cores. It is what I am currently doing anyway. So there is also the possibility to simply physically connect GPIO or UART or MIDI pins and let them talk this way.

To be clear, if you want to program both Ksolotis at the same time you will need to connect each via its own USB cable.

TL;dr I believe it is almost there! A bit unstable and needs some error handling etc. but this looks really fun! It will essentially make Axoloti twice as powerful, twice the IO, GPIO, offer the sends and receives scheme some of you rely on... Just thought I'd share haha.

[Paranormal Patroler]

This is pretty mindblowing.

How would one go around patching both Ksolotis though?

[Sebastian]

The screenshot is my actual screen.

Open two instances of the patcher and go to Board > Select Board...

There you can name your boards which helps a lot.

[Blindsmyth]

Anyone ever heard of the mysterious and elusive SPI-link?

Old legends have it that this feature would allow users to connect two Axolotis, let them enter a spiritual union and share audio and control data between each other.

Omg! Are you aware that you just turned yourself into a living legend with this???!!

"Why is this a big deal? I don't want to complicate things and could just connect them via physical audio jacks and MIDI, or no?", is what I thought. Only when some users shared their use cases for their Axolotis it became clear how big a deal this could be.

Yess!

The SPI is fast enough so I consider making it 6 channels duplex (currently 4). I created objects to optionally pack 16 parameters of control data into any of the channels.
(The original code had placeholders for packing up a lot of extra data like sharing MIDI and "Axoloti Control" data which is a mythical piece of hardware designed by Johannes mere mortals like us will never see, but I'd prefer keeping it simple and modular. As in, the synced Core should only receive the master Core's MIDI if you want it to: you can just pack it up and send it via a free channel.)

Back in the ancient times before the Pandemic, I had the honour of seeing one of the Axo Control boards by the Grandmaster himself. It was a great design, maybe a bit too ambitious in hindsight. Like a the enclosure was supposed to be the PCB at the same time, with deep integration of displays and encoders with rings, 16 buttons and a set of dedicated objects for this. There were like several prototypes, personally all them would have been fine with me
Simple and Modular sounds like exactly what we want!

I currently am quite certain that it is possible to stack the two Cores. It is what I am currently doing anyway. So there is also the possibility to simply physically connect GPIO or UART or MIDI pins and let them talk this way.

For me connecting pin PA2 to PA3 on the other board was working very well (this is UART I guess) together with the extra midi IO patch by hugo.
You need hack into your midi out objects though to make this work.
Alternatively you could just route one of the internal midi ports to the pin. If we can get the object contributor system up again, I'd be happy to share this. I think this extra midi connection opens up a lot of possibilities.

My big question is now: When can I throw my money at you and order like 2+ boards???

[poetaster]

SPI is really cool. 4 duplex is enough for my needs

So I finished the first Ksolotibox pics tomorrow. Here a sound sample of a euclidean sampling beat box

MP3 https://poetaster.de/media/ksoloti_euclid_1.mp3

[Sebastian]

Have I mentioned a batch of Ksoloti Cores will be available at Thonk soon?

So I finished the first Ksolotibox pics tomorrow. Here a sound sample of a euclidean sampling beat box
MP3 https://poetaster.de/media/ksoloti_euclid_1.mp3

Wow the first sound sample! Looking forward to the pictures!

You're right, 4 channels duplex are enough, I was just thinking about adding some k-rate channel and making additional send/receive objects for k-rate data?

[Paranormal Patroler]

Have I mentioned a batch of Ksoloti Cores will be available at Thonk soon?

Will it be a DIY thing or just the board with all components pre-soldered?

[BJG]

Have I mentioned a batch of Ksoloti Cores will be available at Thonk soon?

Wow! Amazing!

[Sebastian]

Will it be a DIY thing or just the board with all components pre-soldered?

This first batch will be just the Core, just like the one you had for testing.

Next there will likely be a DIY box available from Thonk, probably as full kit with some easy soldering required (pin headers, pots, jacks, that sort of thing).

[Paranormal Patroler]

Will it be a DIY thing or just the board with all components pre-soldered?

This first batch will be just the Core, just like the one you had for testing.

Next there will likely be a DIY box available from Thonk, probably as full kit with some easy soldering required (pin headers, pots, jacks, that sort of thing).

I am so getting more Such an exciting project!

[Blindsmyth]

You're right, 4 channels duplex are enough, I was just thinking about adding some k-rate channel and making additional send/receive objects for k-rate data?

It would definately be more convenient that way. But the option of midi is already there. Sending K-rate signals via midi is quite easy.
From my experience sending bigger integer numbers between boards is a bit inconvenient using midi. A value like 247089 samples for example. In the end I converted the value and used pitch bend messages to send sth like this from one board to another. A direct way of patching this via this spi link is a great feature but not a must have imho.

Have I mentioned a batch of Ksoloti Cores will be available at Thonk soon?

[poetaster]

I had one question about pwm. I was using the four input gpio/out/pwm which this is no ksoloti version of. Looks like mabye copy the factory object and set the right pins. The single led example for ksotoli

Code: Select all

pwmStart(&PWMD8, &pwmcfg);
palSetPadMode(GPIOC, 6, PAL_MODE_ALTERNATE(3));
PWMD8.tim->CCER |= STM32_TIM_CCER_CC1NE | STM32_TIM_CCER_CC1NP;

If I was to use the original from Johannes how do I specify the pins ?

Should be just like:
Init:

Code: Select all

pwmStart(&PWMD4, &pwmcfg);
palSetPadMode(GPIOB, 8, PAL_MODE_ALTERNATE(2));
palSetPadMode(GPIOB, 9, PAL_MODE_ALTERNATE(2));

...
pwmEnableChannel(&PWMD4, 2, (pwmcnt_t)(inlet_pb8>=0?inlet_pb8>>15:0));
pwmEnableChannel(&PWMD4, 3, (pwmcnt_t)(inlet_pb9>=0?inlet_pb9>>15:0));

or? Wasn't sure about the &PWMD8 vs PWMD4 ....?

[poetaster]

Have I mentioned a batch of Ksoloti Cores will be available at Thonk soon?

Cool! Thonk is cool. Happy customer of many years.

So I finished the first Ksolotibox pics tomorrow. Here a sound sample of a euclidean sampling beat box
MP3 https://poetaster.de/media/ksoloti_euclid_1.mp3

Wow the first sound sample! Looking forward to the pictures!

You're right, 4 channels duplex are enough, I was just thinking about adding some k-rate channel and making additional send/receive objects for k-rate data?

Just a quick pic, but it's just fast and dirty prototyping to see that I can get out of the board at least what the axoloti does (affirmative!).


I'm thinking of some gill like interfaces, in the main to support stuff like rotary encoders and some jacks for external controllers (ie. footpedals/switches).

[Sebastian]

I had one question about pwm. I was using the four input gpio/out/pwm which this is no ksoloti version of. Looks like mabye copy the factory object and set the right pins. The single led example for ksotoli

Code: Select all

pwmStart(&PWMD8, &pwmcfg);
palSetPadMode(GPIOC, 6, PAL_MODE_ALTERNATE(3));
PWMD8.tim->CCER |= STM32_TIM_CCER_CC1NE | STM32_TIM_CCER_CC1NP;

If I was to use the original from Johannes how do I specify the pins ?

Should be just like:
Init:

Code: Select all

pwmStart(&PWMD4, &pwmcfg);
palSetPadMode(GPIOB, 8, PAL_MODE_ALTERNATE(2));
palSetPadMode(GPIOB, 9, PAL_MODE_ALTERNATE(2));

...
pwmEnableChannel(&PWMD4, 2, (pwmcnt_t)(inlet_pb8>=0?inlet_pb8>>15:0));
pwmEnableChannel(&PWMD4, 3, (pwmcnt_t)(inlet_pb9>=0?inlet_pb9>>15:0));

or? Wasn't sure about the &PWMD8 vs PWMD4 ....?

Ok wow this is going to be tricky to explain.

Setting up PWM and the corresponding settings depend on at least three parameters that must be set correctly for each respective pin. Also only certain pins even support PWM.

You probably remember the Ksoloti schematics folder:
https://www.dropbox.com/scl/fo/ougk3w4b ... kc3ze&dl=0

On the first page of ksoloti_core_vXX.pdf you see the huge box in the center, which is the STM32F4 with all its pins and possible functions. Now check pin PC6, which connects to LED2. there you will see something like this:

Code: Select all

&PWMD8

here means timer 8 is used to generate the PWM signal. You could also use

Code: Select all

&PWMD3

because that pin happens to support it too.

HOWEVER with each of these settings (ST calls them "alternate functions") you have to make sure you activate the right number of alternate function. Which you can see in action here:

Code: Select all

palSetPadMode(GPIOB, 8, PAL_MODE_ALTERNATE(2));

The next factor is the respective channel of the timer that this pin can connect to. You see it here:

Code: Select all

pwmEnableChannel(&PWMD4, 2, (pwmcnt_t)(inlet_pb8>=0?inlet_pb8>>15:0));

To make things even more fun, &PWMD4, 2 means channel 3 because ChibiOS starts counting at zero here. So if you want channel 1 of timer 3 it would translate into &PWMD3, 0.

How do we know which number we need? The STM32F427 datasheet has a big table with each corresponding number, like below:

So in plain English, if I want to attach timer 3 to pin PC6, I have to configure it as PAL_MODE_ALTERNATE(2). If I want to attach timer 8, I need PAL_MODE_ALTERNATE(3).

P.S. PC6 can also be run with timer 3, channel 1. So why are we not doing that? After all some of the other pins use timer 3 to generate PWM. Well that exactly is the problem. Look at pin PB3. Timer 3, channel 1. So in plain English, if you want both pins to blink independently, you cannot set them to the same timer, same channel (they would blink in unison if you did).

So long story short... wait, I "lost the red thread"... what were you trying to set up? Anyway your code above should be correct also for Ksoloti.

Code: Select all

pwmStart(&PWMD4, &pwmcfg);
palSetPadMode(GPIOB, 8, PAL_MODE_ALTERNATE(2));
palSetPadMode(GPIOB, 9, PAL_MODE_ALTERNATE(2));

...
pwmEnableChannel(&PWMD4, 2, (pwmcnt_t)(inlet_pb8>=0?inlet_pb8>>15:0));
pwmEnableChannel(&PWMD4, 3, (pwmcnt_t)(inlet_pb9>=0?inlet_pb9>>15:0));

[Sebastian]

Just a quick pic, but it's just fast and dirty prototyping to see that I can get out of the board at least what the axoloti does (affirmative!).

Very nice! Congratulations, you are now the first ever Ksoloti builder.

[Yot-21]

Are there any OSX users here who used or are using Axoloti? I have never used OSX so I am not sure about compatibility. The old installation guide says

Code: Select all

macOS Catalina is NOT supported at this time.
(we are looking into compatibility issues at this time, and do not have a timeframe on resolving this yet)

Which sounds serious, Catalina itself isn't even maintained yet and seems to be like four versions behind the most current MacOS version!

Hey Seb,

MacOS Axoloti/Akso user here.
There's no problem running the Editor when it's already installed. But it's another story when you have to install it on a new machine.
The last versions of MacOS are super picky with non-identified developper apps.

I had to open each .h files (or .c files, I actually don't remember well) one by one as admin (right click then "open", then "open anyway") to kind of authorize the main app to access theses files. That's why I think it's a security related issue with OSX and unidentified developers app. That might be solved with some kind of Installer but this is just a guess.

[hitachii]

Are there any OSX users here who used or are using Axoloti? I have never used OSX so I am not sure about compatibility. The old installation guide says

Code: Select all

macOS Catalina is NOT supported at this time.
(we are looking into compatibility issues at this time, and do not have a timeframe on resolving this yet)

Which sounds serious, Catalina itself isn't even maintained yet and seems to be like four versions behind the most current MacOS version!

Hey Seb,

MacOS Axoloti/Akso user here.
There's no problem running the Editor when it's already installed. But it's another story when you have to install it on a new machine.
The last versions of MacOS are super picky with non-identified developper apps.

I had to open each .h files (or .c files, I actually don't remember well) one by one as admin (right click then "open", then "open anyway") to kind of authorize the main app to access theses files. That's why I think it's a security related issue with OSX and unidentified developers app. That might be solved with some kind of Installer but this is just a guess.

Ah yes, I was trying to remember what it was about installing the patcher on my Catalina Mac that was both tricky and time consuming, and this is exactly what I had to do too.

[Sebastian]

Ok got it, at least it is "only" MacOS trust issues, not some core incompatibility... Maybe there is a command to batch alter those permissions.

[poetaster]

I had one question about pwm. I was using the four input gpio/out/pwm which this is no ksoloti version of. Looks like mabye copy the factory object and set the right pins. The single led example for ksotoli

So long story short... wait, I "lost the red thread"... what were you trying to set up? Anyway your code above should be correct also for Ksoloti.

Code: Select all

pwmStart(&PWMD4, &pwmcfg);
palSetPadMode(GPIOB, 8, PAL_MODE_ALTERNATE(2));
palSetPadMode(GPIOB, 9, PAL_MODE_ALTERNATE(2));

...
pwmEnableChannel(&PWMD4, 2, (pwmcnt_t)(inlet_pb8>=0?inlet_pb8>>15:0));
pwmEnableChannel(&PWMD4, 3, (pwmcnt_t)(inlet_pb9>=0?inlet_pb9>>15:0));

Ok, in short, the original objects should work cause it's all pin compatible What I was using was 4 PWM LEDs all attached to encoders. I think the the two pins above are fine but which others? I 'think' this would work:

Code: Select all

INIT
static const PWMConfig pwmcfg = {400000, /* 400kHz PWM clock frequency.  */
	4096, /* PWM period is 4096 cycles.    */
	NULL, 
	{{PWM_OUTPUT_ACTIVE_HIGH, NULL}, 
	{PWM_OUTPUT_ACTIVE_HIGH, NULL},
	{PWM_OUTPUT_ACTIVE_HIGH, NULL}, 
	{PWM_OUTPUT_ACTIVE_HIGH, NULL}},
	/* HW dependent part.*/
	0};

pwmStart(&PWMD3, &pwmcfg);
  
palSetPadMode(GPIOA, 6, PAL_MODE_ALTERNATE(2));
palSetPadMode(GPIOA, 7, PAL_MODE_ALTERNATE(2));
palSetPadMode(GPIOB, 0, PAL_MODE_ALTERNATE(2));
palSetPadMode(GPIOB, 1, PAL_MODE_ALTERNATE(2));

KRATE
pwmEnableChannel(&PWMD3, 0, (pwmcnt_t)(inlet_pa6>=0?inlet_pa6>>15:0));
pwmEnableChannel(&PWMD3, 1, (pwmcnt_t)(inlet_pa7>=0?inlet_pa7>>15:0));
pwmEnableChannel(&PWMD3, 2, (pwmcnt_t)(inlet_pb0>=0?inlet_pb0>>15:0));
pwmEnableChannel(&PWMD3, 3, (pwmcnt_t)(inlet_pb1>=0?inlet_pb1>>15:0));

DISPOSE
pwmStop(&PWMD3);

Or?

That's all code generated by the original gpio/out/pwm objects.

[Sebastian]

Yes this looks correct.

[Blindsmyth]

Hey, I'm just wondering:
Would it be possible to also chain 3 boards with this SPI feature in some kind of ring topology?

That way we could create a MEGAksoloti with 6 in 6 outs.

No needs for external mixers here, when connecting several instruments, and lots of processing power

[Sebastian]

Sounds tempting but it is not planned so far. The SPI link is reading and writing data simultaneously which means only one pairing is possible. Otherwise it would require a rewrite of the SPILINK part, more memory etc. and your Axolotis would spend some amount of their memory just to send and receive things between each other.

EDIT: wait now that I think about it ... the send and receive lines are sort of independent so maaaybe with a bit of wiring you indeed pull this off by daisy-chaining them.

Audio RXTX:
Master -> sync one
Sync one -> sync two
Sync two -> Master
Ist this what you had in mind?


My point was only that I wouldn't want to inflate the firmware for this haha. Since I am achieving better stability now I'll try it out...

I got the SPI link working but still get occasional pops and crackles. Probably a timing issue as the connections are super short. Or maybe a USB ground loop even?
Any SPI / frame sync experts out there before I try to find my old logic analyzer that likely isn't fast enough for the signals anyway?


EDIT: I believe I have found the bug. For those interested: as so often in embedded it was about what the code wasn't doing. Literally ONE BIT of data was not set. Namely the MSTR bit in CR1 of the master's SPI configuration. It should have been implicitly set but oh well.
(Keywords: STM32F4 SPI full duplex DMA SAI audio sample sync)

This is my test rig. Just 4 pins for SPI and 1 pin for the required codec sync (long story). Ground goes through the metal standoffs and also via USB...