-
Notifications
You must be signed in to change notification settings - Fork 86
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Another attempt to support configuration TGs and polyphony #690
Conversation
Build for testing: |
Hello Kevin, thank you very much for your efforts. I tested my miniDexed with a Raspberry 4 and found out the following:
Notes: If you work with 16 TGs, I would divide the miniDexed into a lower and an upper area. The following menus would then be conceivable: |
Brilliant - thanks for that - yes, I've just noticed the polyphony too! I'll take a look. I think the idea was really to go with safe defaults re TGs and polyphony, to ensure no issues - there was some issue with different engines? Anyway, I set the max for a Pi 4 to 24, but we can up it to 32 if that works ok. A dual-performance idea sounds really cool! But I won't think about that as part of this change, I think for now lets get the basics assured and then we can move on from there. Thanks for giving it a go! I'm slowly working through a few different configurations myself this morning :) Kevin |
Ok, so limiting polyphony is working, just not in a very obvious way! This is a printout of an instrumented Synth_Dexed showing which note "slot" it is using as I press 6 notes, then release them in the reverse order, when the system is configured for 4 note polyphony. Notice how it keeps reusing "slot 1" which isn't the first note pressed... Then when the other notes that were in "slot 1" are released nothing happens as the slot was reused and already released... This is just the algorithm within Synth_Dexed so not related to anything we do. Note there are 16 printouts for max_notes = 4 as each TG is initialised for 4-note polyphony and I have 16 configured. Kevin |
Ah this is fun. When loading a 8 TG performance into a 16TG setup, all unused TGs get set to MIDI OMNI... I'll have to change that otherwise every performance is a little "Brass 1" heavy :) |
…o higher defaults on Pi 4 and 5.
Ok, so I've tested the build on the following:
Haven't checked higher polyphony, but have checked configuring for lower. Latest build fixes performance issue with MIDI channels and sets max polyphony to 32 on Pi 4 and 5 with the defaults being a "safe" 24 and 32 respectively. Do please check with your existing configurations - I want to ensure all the standard options haven't messed up! :) I still need to check MIDI TG or Program buttons Up/Down, so if anyone is already using those and gets there first - let me know! Note: I didn't do wrap around with the TG buttons - just with the menu. Kevin |
… config if not present.
Build for testing: |
As always, thanks a ton for your great contribution! Allow me a question though:
Did you do this for a special reason or just because you didn't come around to doing it yet? Personally I am a huge believer in consistency. I think things should work in the same way across an user interface. It already drives me nuts that the performance selection works differently from the voice selection (having to click vs. not having to click). So I am curious to understand whether you made that decision intentionally or just due to not having it implemented yet. |
with a RPi 4 I get the following polyphony: |
I agree consistency is important, but the TG up/down is a very different interaction to the menus, so I thought that it was more important, especially if a remote button (i.e. MIDI TG buttons) is being used that one can't "get lost" working out which TG is selected. I thought that with wrap around that was a real danger. This way, keep pressing "down" and you'll eventually get to the first TG, and same with "up" to the last, so it would be easy to re-orient yourself if selecting them with no UI nearby to see what is going on. That was my thinking anyway - happy to consider alternatives! (the logic in the code is very different for the two cases anyway, so I'm not making things more complicated by doing things differently) Kevin |
Hmm. No idea why that is. Unless this is the first version linked in this thread - the first build limited the Pi 4 to 24 note polyphony, but the latest build should allow 32 I think? Kevin |
Ok, actually I might have an idea... looks like this ">=" should be a ">" :) Kevin |
Build for testing: |
Now I can play the RPi 4 with 32 voices polyphony. |
Just to be sure, is it polyphony per TG or for the whole ? |
It means the polyphony for each TG 🤩 |
I love your idea ! It's perfect for having 8x TG in the lower part, and load a complete drum kit section in the upper part, i really hope this will be push later :) |
I'm afraid that is probably a fair bit of significant work and we'd need to really pin down the behaviours we want in the various different configurations (8TG vs 16TG vs single vs split performances, etc). We'd also need to decide on a MIDI strategy for the two collections too - and that is then really getting to the point of needing some kind of system level MIDI map in my view... But I'll ponder while we're giving this one a shakedown first! Kevin |
What comes to mind in this context Performance handling: #581 (comment) |
Has anyone else been able to check this firmware on their own configurations? I'd like to know we haven't broken backwards compatibility and "normal" configurations with this change. Kevin |
Build tested on my Rasp 3 and everything is working fine ! About this tho, you should add wrap to TG because as soon as we can see theTG number on the screen, we are never lost. |
Im using a pi 3 so no big changes in the # of TGs or poly, but everything seems to be working fine for me. |
Great! Thanks for letting us know. Kevin |
I think this is probably at a point where it can be merged in, then I can start thinking about what might be worth doing next - I'm trying not to have several things on the go at once and I really don't want to be continually merging against an updating main branch! (This is where having a more quickly merged dev branch would make life quite a bit easier and mean things could be added to it more quickly ;)) Kevin |
Thank you very much @diyelectromusic. As always, please don't forget to update the wiki accordingly. |
Supports TG configurations as follows:
Pi 1 = 1 TG
Pi 2,3 = 8 TG
Pi 4,5 = 8 or 16 TG (default 8)
and polyphony as follows:
Pi 1 = 8
Pi 2,3 = 16
Pi 4 = 24 (default 16)
Pi 5 = 32 (default 16)
Relevant minidexed.ini parameters are:
Menus seem to working ok for different TG configurations. Note - the main menu (TG/effects/performance) now wraps around.
If you fancy having a look, the following all has to be tested:
-- 8TG performance into 16TG system
-- 16TG performances into 8TG system
-- loading/saving 8TG performances with 8TG system
-- loading/saving 16 TG performances with 16TG system
And probably a whole pile of other things too. Basically if you fancy giving this a go with your standard configuration, please do!
I'll start on with some this myself too, so expect updates over the next week or so as I find things wrong, but please report any errors, asserts from the console, weirdness, etc here with details of your configuration and I'll take a look!
Kevin