This topic is just to show explanatory diagrams for two patches on patchstorage
If you’re a regular reader you’ll have already seen them here and here.
Both use loopback techniques, so if this is being read after the next major firmware update, hopefully they are both redundant!
EDIT: If you have a 8 (or fewer) states and want to cycle through them up and down, you might want to try adapting the patch here first (it needs no loopback)
There’s also a simpler patch further up the thread that can handle up to 16 states uni-directionally.
2 Likes
Patch 1: Converting Program Changes to an ‘incrementer’ CC
Input is Program Change Number
Output is one of two values representing Program-Up and Program-Down
Steps:
2 Likes
Patch 2: Converting CC switch to increment Program Change
Input is On-Value from an Up switch and a Down switch
Output is Next/Previous Program Change Number
steps:
2 Likes
Patch 2 now updated for Virtual mappings.
Loopback no longer needed.
This has made the preset simpler. Let me know if it needs any explanation.
I needed to introduce a tiny note Delay to get this to work.
Interesting…(IMO!)
1 Like
Patch 1 now updated for Virtual mappings.
Loopback no longer needed.
This has made the preset considerably simpler...
from 19 pipes:
down to 10:
This is mainly because we can lose all the feedback prevention pipes added for loopback safety.
Another Filter is saved by using Transform’s new Drop mode 
Here’s the simplified schematic…
…probably best understood by working backwards:
-
Transform 4 & 3 deal with PCs above & below the last stored value…
-
…but their ranges both include that value, so Transform 2 drops it before it reaches them.
(this also means that nothing comes out of MIDI-A if the same PC is repeated)
-
Transform 1 creates the update CC before the PC message is replaced/drpped; it is set After the messages have passed through so that the update occurs ready for the next PC event
PS. @klutio: for you if you’re still using this technique…
1 Like
