2.0.0 Too many calls to Python/weird behaviour when selecting a sound in the grid

[bboc]

To debug an adaptation I am writing I'm logging all function calls in the adaptation, here's what I get when I click ONCE on a patch in the grid:

20:20:34: info Adaptation: : calculateFingerprint(message)
20:20:34: info Adaptation: : calculateFingerprint(message)
20:20:34: info Adaptation: : calculateFingerprint(message)
20:20:34: info Adaptation: : calculateFingerprint(message)
20:20:34: info Adaptation: : calculateFingerprint(message)
20:20:34: info Adaptation: : calculateFingerprint(message)
20:20:34: info Adaptation: : calculateFingerprint(message)
20:20:34: info Adaptation: : name(): 'Modor NF-1(m)'
20:20:34: info Adaptation: : calculateFingerprint(message)
20:20:34: info Adaptation: : name(): 'Modor NF-1(m)'
20:20:34: info Adaptation: : bankDescriptors()
20:20:34: info Adaptation: : bankDescriptors()
20:20:34: info Adaptation: : bankSelect(9, 6)
20:20:34: info Adaptation: : generalMessageDelay()
20:20:34: info Adaptation: : name(): 'Modor NF-1(m)'
20:20:34: info Sending program change to Modor NF-1(m): program 06-14
20:20:34: info Adaptation: : calculateFingerprint(message)
20:20:34: info Adaptation: : name(): 'Modor NF-1(m)'
20:20:34: info Adaptation: : calculateFingerprint(message)
20:20:34: info Adaptation: : name(): 'Modor NF-1(m)'
20:20:34: info Adaptation: : bankDescriptors()
20:20:34: info Adaptation: : name(): 'Modor NF-1(m)'

Any idea why KnobKraft calculates 10 checksums in order to send one program change? There's no other sounds with the same name in the database?

My assumption was KnobCraft would send the patch to the edit buffer, because the patch might already have changed on the device since the last import.

[christofmuc]

Lol, no, the md5 is not cached in the C++ part. That looks like an easy optimization possibility, I noticed things start to get slower and slower on the Python side, and it seems we need to reduce the number of roundtrips between C++ and Python as they take a lot of time.

[bboc]

It appears there's a lot of room for improvement, when I import banks I get a massive pile of calls that could easily be reduced. I suggest you do this for an adaptation of one of your own synths, just print the names of the functions, and you'll see they can probably be reduced to 5-10%.

[christofmuc]

Will do! This is a bigger story because we need to make sure the value in the C++ part of the program is still up to date, else mysterious bugs will pop up.

Regarding the program change vs edit buffer send - yes, this is a new feature and I am not completely sure if the full automatic works (i.e. if you modify the synths content and do not import again, it might select the wrong program). Maybe we need a global switch to turn this on or off? For some synths, it is an enourmous help because they are terribly slow to write to edit buffer (Hydrasynth for example).

[bboc]

A switch (per device) is a great idea. Is the program change the only place where the Midi Channel is required?

[christofmuc]

Some devices use the channel equivalent to the device ID, and because I started with one of these the code is not really clear about where is which.

The masterkeyboard routing also uses the MIDI channel.

And yes, synths that do not have an edit buffer also need program changes when using a default program place to fake an edit buffer, so they also need the MIDI channel (e.g. Kawai K3).

[christofmuc]

Implemented a name and fingerprintCache im C++ to reduce the number of round trips between C++ and Python, and also made sure to call renamePatch() only when the result of nameFromDump() is different from the desired new name. That did accelerate the Andromeda A6 adaptation by several orders of magnitude, so I hope we're good for a while.

[christofmuc]

Will be part of the 2.0.7 release building right now