How can I solve this Alesis synth problem with Zynthian?

Since Zynthian can do just about anything MIDI or audio related I assume I can use it to solve this problem but I’m not sure what’s the best approach.

I have an Alesis Fusion which is a 60 pound, 88 weighted key monster of a synth. It’s really an amazing synth but it has an annoying peculiarity. SOME Fusions were shipped with a Fatar TP40 keybed that reports velocity a little differently for the white keys and black keys. The black keys report about 10-20 points higher in note velocity. My first thought was using the Zynthian MIDI filter rules to fix this but those rules do not allow for modification of velocity values.

I can turn off local keyboard control on the Fusion and route it’s note events to the Zynthian MIDI IN and then route the Zynthian MIDI OUT back to the Fusion. So, what I need to do is setup a MIDI route processor that reduces the velocity of only black key events by about 15 points. Is Puredata the best solution?

Thanks,

Scott

An lv2 midi chain component is probably the way forward.

I realize you may want a workaround now, but I also think this would be a worthwhile enhancement request - issue for Zynthian.

Have you tried changing the velocity curve and/or velocity scaling values on the Fusion synth to see if you can get better results? If not, you should be able to make changes by going to Global/Settings/General menu on the Fusion.

2 Likes

Yeah, the Velocity curve can help tame it by compressing the Velocity values a bit but that is suboptimal. I figured I could fix it properly with my little headless RPi3 Zynthian.

'ow 'bout moonly.lv2? Use the script at moony-lv2-scripts/scale_velocity.lua at master · SpotlightKid/moony-lv2-scripts · GitHub

try setting the note_ranges variable to “22, 25,27, 30,32,34, 37,39, 42,44,46, 49,51, 54,56,58, 61,63, 66,68,70, 73,75, 78,80,82, 85,87, 90, 92,94, 97,99, 102,104,106”
set vel_scale to 1.0, vel_offset to -15
That should cover all black keys on a piano and do you right. Check me though, it’s late. :slight_smile:

1 Like

Good call @ssj71. I was going to suggest Moony. It provides a scriptable MIDI plugin, kinda write-you-own in a scripting language. You could derive the ranges with a function.

Moony A1 x A1 has a preset called, “Tutorial 5: MIDI Velocity Curve Interpolater” which could serve as a starting point.

Nice! Thanks for the input. Sounds about perfect. I’ve not yet written any LUA but that shouldn’t be an issue.

Yep! I started to look at the code but decided it would take too much of my time to refine it. The syntax is fairly simple but newbies to the language will need to refer to some docs / examples for the subtleties. You could look here for an example of how to programmatically calculate the black notes. We do it to draw keyboards in the UI.

I looked at this. The MIDI tools allow for a solution I think.

  • Filtering black keys and routing them to secondary channel.

  • Velocity gets modified on black key events routed to secondary channel

  • Modified black key events are routed back to the original channel.

This should work for a simple mono-timbral example but falls apart for multitimbral use.

I’m going to have to learn more about the Moony tools.

I just tried to run Moony yesterday so I deleted all layers and added Moony A1 x A1 atom processing and used the simple “through” preset. This results in a total lockup of the Zynthian UI with webconf still running normally. Any Moony atom processor I tried crashed the UI.

I also tried Moony control processors like C1xC1 through and that at least didn’t crash the UI.

So Control processors seem stable by themselves. Combination processors like C1+A1xC1+A1 also seem stable. Atom-only processors like A1xA1, etc. all lock the UI.

This could be total ignorance on my part. I was just trying to fire up these plugins to try them out. Nevertheless, the UI lockup is a problem.

Much reading to do.

Is the Moony Atom processor crash something I did? I assume it’s a bug in the atom plugins.

I haven’t seen that. Provide a snapshot to demonstrate the issue.

Well, I tried it today, after updating to the new stable version, and no crash. All I had to do before with the older UI was load up Moony A1 x A1 and the whole UI would lock.

So it appears to be fixed.

1 Like