Ruben

I have been working on developing a microtonal organ with Max, and I have a problem that I only see when the patch reaches a certain scale. That means I cannot isolate the problem in a smaller patch. I first give you the download link for this organ:

https://sourceforge.net/projects/microtonalorgan/

The patch contains 4 fluidsynth objects, each of then handle more than 100 midi channels. For each of them, tunings or program changes should be changed rapidly on cue. For tunings it is working quite well. The problem is the program changes (the main patch: "Store registrations and tuning presets"). If everything happens quickly, many program changes will be ignored at some point. I wonder where that happens. Does the fluidsynth object ignore messages arriving too rapidly, or is it Max itself? 

For a functional register preset on a large organ, it would be good to have all changes triggered within a second. Through experiments I increased the trigger delays using the argument #0. In the subpatch 'SingleMenuItem and 'p RubenDictMenuStorage, each program change is delayed by (#0-1000)*26. This may add up to a very long time, some times close to a minute for all changes to take place. I have experimented, and anything less than this delay creates inconsistent triggering of program changes. What would be optimal is having a cue where messages are delayed just as long as necessary but never ignored.

Do you have suggestions, is it Max or the Fluidsynth object? Would it be more efficient to create such things in code rather patch programming? (I have that experience from Open Music. One patch could take 4 hours to process. Rewriting everything to lisp, I was down to 2 minutes. ) I would be happy for some hints.

I have been working on developing a microtonal organ with Max, and I have a problem that I only see when the patch reaches a certain scale. That means I cannot isolate the problem in a smaller patch. I first give you the download link for this organ:
https://sourceforge.net/projects/microtonalorgan/

The patch contains 4 fluidsynth objects, each of then handle more than 100 midi channels. For each of them, tunings or program changes should be changed rapidly on cue. For tunings it is working quite well. The problem is the program changes (the main patch: "Store registrations and tuning presets"). If everything happens quickly, many program changes will be ignored at some point. I wonder where that happens. Does the fluidsynth object ignore messages arriving too rapidly, or is it Max itself? 

For a functional register preset on a large organ, it would be good to have all changes triggered within a second. Through experiments I increased the trigger delays using the argument #0. In the subpatch 'SingleMenuItem and 'p RubenDictMenuStorage, each program change is delayed by (#0-1000)*26. This may add up to a very long time, some times close to a minute for all changes to take place. I have experimented, and anything less than this delay creates inconsistent triggering of program changes. What would be optimal is having a cue where messages are delayed just as long as necessary but never ignored.

Do you have suggestions, is it Max or the Fluidsynth object? Would it be more efficient to create such things in code rather patch programming?  (I have that experience from Open Music. One patch could take 4 hours to process. Rewriting everything to lisp, I was down to 2 minutes. )  I would be happy for some hints.

Hello,
I have been working on developing a microtonal organ with Max, and I have a problem that I only see when the patch reaches a certain 

Triggering a large number of program changes