[WIP] Part 1-3 + Part Drum + Layer 1 performance loading#950
[WIP] Part 1-3 + Part Drum + Layer 1 performance loading#950soyersoyer wants to merge 6 commits intoprobonopd:mainfrom
Conversation
|
Build for testing: |
|
Should we have a separate TG reverb (or per TG group reverb)? |
soyersoyer
changed the title
|
Build for testing: |
|
Thanks @soyersoyer. So if I understand this correctly, this one is about loading 2 performances with 8 voices each. |
|
This could be good if you don't know in advance how you want to combine the 8TG performances and you don't have multiple Minidexeds. For example, you could load a piano into Part1, drums into Part2, (bass into Part3, if there will be one) |
soyersoyer
changed the title
|
I also added part 3. With fast=true it works without crackling on rpi4. It's fun with a 4 channel sequencer and with a drum machine :) I tried part4 also (32TGs), but some weighty performance caused crackling. There is sometimes crackling with 24TGs as well. |
|
Build for testing: |
|
Build for testing: |
|
Build for testing: |
|
Build for testing: |
soyersoyer
changed the title
|
Build for testing: |
|
After I added fast=true to the top of the cmdline.txt (not after the comments), the frequency changed to 1500 MHz. Now it always starts in fast mode (otherwise it wouldn't work) |
|
Build for testing: |
It works with WaitForEvent, without disabling IRQs. Before this the WaitForInterrupt was used, and these findigs were useful: Before checking the atomic variable, disable IRQs to avoid missing the wake-up event. https://marc.info/?l=linux-arm-kernel&m=114684008423863&w=2 https://electronics.stackexchange.com/questions/12601/best-pattern-for-wfi-wait-for-interrupt-on-cortex-arm-microcontrolers add dsb before wfi torvalds/linux@8553cb6 https://github.com/torvalds/linux/blob/master/arch/arm/mm/proc-v7.S https://github.com/torvalds/linux/blob/master/arch/arm64/kernel/idle.c torvalds/linux@9cce7a4
the addreverb function scales and adds the reverb to the out array, thus skipping the intermediate buffer
Demo: Very basic part performance load implementation. Performance > Part 1 loads the performance into to TG 1-8 and adds 0 to each TG channel. Performance > Part 2 loads the performance into to TG 9-16 and adds 3 to each TG channel. Performance > Part 3 loads the performance into to TG 17-24 and adds 7 to each TG channel. Performance > Part Drum loads the performance into to TG 25-32 and adds 8 to each TG channel. Performance > Layer 1 loads the performance into to TG 33-40 and adds 0 to each TG channel. This is just a test of how it sounds this way. Every part has a reverb. ToneGenerators=40 should be added to the minidexed.ini so you need rpi4 or rpi5. It starts the Pi with fasts mode, so it is possible that you will need a heatsink.
soyersoyer
changed the title
|
I changed Part4 to drum channel (9) and added another layer to Part1 (and 8 new TGs). |
|
Build for testing: |
soyersoyer
changed the title
My Raspberry Pi 4 won't boot. Config.txt doesn't have any modifications. Do I need to adjust anything? Peter |
|
You need to set ToneGenerators=40 in the minidexed.ini |
|
FYI: I am currently working on a graphical performance editor, a port of MiniDexed to Linux (including an embedded OS for Raspberry Pi), Windows, macOS, FreeBSD, and VSTs. These are all meant to have interchangeable performances. Hence I am unlikely to change the performance format anytime soon. |
|
This does not change the performance file, it just loads the parts into the TGs. The performance file, however, will definitely change due to the fx chain later. |
@probonopd There's surely a solution (fork). Don't get me wrong, but the editor shouldn't be the defining (limiting) element of such a project. Peter |
|
I would like to jam with MiniDexed in the easiest way possible. I think these features would fit in this repo, but I'm fine with them elsewhere too. |
|
@soyersoyer I'd love to use a lot of it right away and would be happy if it were implemented. :-)
The KY-040 encoder works perfectly in my setup; every step on the encoder does what it's supposed to. I added the 10nF capacitors directly to the encoder ( CLK to ground and DT to ground ), and that's it.
I don't understand this funktion. "adds 0 to each TG channel" ??? I've given some thought to the audio path (mixer including effects). If you're interested, I'd be happy to talk to you about it. Peter |
Me too! And if the existing ones were integrated as well.
I think it could work fine without the capacitors also. The mt32-pi has a solution how to handle the gray-code.
It will load the performance onto the channel defined by the performance. (usually channel 1) I have rewritten it.
I also have some ideas. |
|
3 participants
Demo:
Very basic part performance load implementation.
Performance > Part 1 loads the performance into to TG 1-8.
Performance > Part 2 loads the performance into to TG 9-16 and adds 3 to each TG channel.
Performance > Part 3 loads the performance into to TG 17-24 and adds 7 to each TG channel.
Performance > Part Drum loads the performance into to TG 25-32 and adds 8 to each TG channel.
Performance > Layer 1 loads the performance into to TG 33-40.
This is just a test of how it sounds this way.
Every part has a reverb.
ToneGenerators=40 should be added to the minidexed.ini so you need rpi4 or rpi5.
It starts the Pi with fast mode, so it is possible that you will need a heatsink.