-
|
I am currently installing a miniDexed in an old master keyboard. The structure is kept very simple. RPi with DAC and Classic MIDI input. The performances are selected via MIDI program change. A display or encoder are not needed. I noticed a few things:
RPi 2 = 4.5 seconds 48 performances, no sysex files, Samsung 32 EVO MicroSDHC UHS-I Grade 1 Class 10, no LCD or OLED. Why?
|
Beta Was this translation helpful? Give feedback.
Replies: 3 comments 6 replies
-
|
I can't comment on the load times, but in terms of performance numbering, it looks like the numbers in the filenames have no meaning in the system. The performance (internal) ID comes from the order in which they are loaded - it doesn't recognise the numerical gaps... But also, as per MIDI spec, the default performance therefore will be "Program 1" which will be translated into MIDI message C0 00 "on the air". Having said that, I do wonder if in this line (https://github.com/probonopd/MiniDexed/blob/main/src/minidexed.cpp#L486), I hadn't spotted that the default performance is hard-coded in as zero or not... I'd have to do some more tests... Kevin |
Beta Was this translation helpful? Give feedback.
-
|
The simplest solution for me was to use a dummy performance at the back. |
Beta Was this translation helpful? Give feedback.
-
|
Ok, yes there is an off-by-one error somewhere, and I suspect that line is the culprit! I'll keep looking... But as I say, with that fixed, having numbers in the filenames with gaps in the sequence is probably a little confusing as we basically ignore them internally... Kevin |
Beta Was this translation helpful? Give feedback.
-
|
Ok yes, as nLastPerformance is incremented every time a performance file is loaded, and as the default performance is always loaded first regardless (so is always in "slot 0") then if there are an additional 127 performances in files, listed with names 001..127 then the following is true:
So on that basis, that line has to be changed from: to: (this is in CMiniDexed::ProgramChangePerformance) But someone else might have to fix that, I probably won't get round to it for a while... Kevin |
Beta Was this translation helpful? Give feedback.
-
|
Great that you found something. 👍🏼 |
Beta Was this translation helpful? Give feedback.
-
|
I don't have a strong view. The code is there, it would be a fair bit to untangle to take it out, and if left does allow a simpler configuration for those that want it I guess...? As I say I think the bigger issue is that the performance numbers give the illusion of a user-recognisable code that actually is irrelevant. If anything those numbers ought to relate to what a MIDI program would show the user, in which case they ought to be consecutively numbered from 002 (the second MIDI Program) through to 128 - by this I mean just renaming the performance files, not changing any code in MiniDexed. Or we could change the code to do what we did with banks/voices and use the read number from the file as the index with which to store them - that way, if the file is "000024_WurlitzerAMP.ini" then MIDI Program 24 (which translates on the wire to 23, or a MIDI msg of C0 17) will match it regardless of the presence of any files of 000023_ or less... but that is a fair bit of code to work through... but I did it for voices/banks, so I could do it for performances too I guess... Kevin |
Beta Was this translation helpful? Give feedback.
-
This is how I did it with my new project described above. Another solution (not in my project but in general) would be to create all 255 performances (+default= 256), the numbering remains incomplete as it is and the gaps are filled with a kind of INIT performance. Then there is probably a new problem when saving new Performances!? |
Beta Was this translation helpful? Give feedback.
-
|
Raspberry Pi 4 has a longer boot times than the previous models because it "takes care of itself" much longer before it even starts booting. With Linux, you don't notice this, as Linux itself starts much longer, but in bare metal, Ultibo, Circle, the difference is huge. RPi4 has its boot code in eeprom (that was not the case in earlier models) and it also tests and fine tunes its DDR4 memory subsystem, and that needs more time than initializing these older DDR2s. After this, the "real boot" is faster on a #4, but as the firmware starts slower, the overall time from power on to a working program is longer too |
Beta Was this translation helpful? Give feedback.
-
|
@pik33 That all sounds very plausible 🕵️ |
Beta Was this translation helpful? Give feedback.
Raspberry Pi 4 has a longer boot times than the previous models because it "takes care of itself" much longer before it even starts booting.
With Linux, you don't notice this, as Linux itself starts much longer, but in bare metal, Ultibo, Circle, the difference is huge.
RPi4 has its boot code in eeprom (that was not the case in earlier models) and it also tests and fine tunes its DDR4 memory subsystem, and that needs more time than initializing these older DDR2s.
After this, the "real boot" is faster on a #4, but as the firmware starts slower, the overall time from power on to a working program is longer too