Hello Everyone. In today’s blog post, I am going to showcase a VST and AU plugin I have written to control the Boss VF-1 hardware unit. I plan to release this in the near future, along with my TC Electronics M300 plugin and my Alesis MidiVerb II plugin.
First off, I am not connected with the companies mentioned above in any way, I am just a big fan of their work and vintage processors which have tons of character.
There are many debates over software versus hardware, in the box, out the box and hybrid. One of the most interesting takes on the debate is that these hardware boxes are like multi-effect DSP units. For example, Roland’s own plugin and algorithms in hardware form. As a result, we have unique spin on effects that were very carefully crafted to fit small chips in innovative ways leading to some classic sounds.
The downside is that in modern times, I am used to software interfaces, plugins. Fast an easy to get what you want, shaping sound with ease. I also don’t like having to keep bending over to dial in settings in my tiny hybrid set-up.
This is where the CRTLR project steps in. CTRLR allows you to build a GUI to interface with your Boss VF-1 hardware and best of all, you can program the plugin to taste through LUA. You can make it work how you want it to work with a modern DAW.
For example, when using the Boss VF-1 hardware, I hate having to remember which preset was used or what was dialled in. Using CTRLR, you can save the preset in your DAW where it automatically loads up when you load the project. You can live control the parameters of the Boss VF-1 and enable them to be automated in Logic.
The downsides are that you have to learn to program LUA and work out how to make the plugins work for you. Well, after several month of scripting and prototypes, I now have a good understanding of how to do this and I’m close to my first release.

Plugin Versions
************************************************************************************
Version 1 (Alpha) – Small test group. Unreleased:
Hardware: For Mac and PC tested on a Mac Pro 2010, MacBook Pro 2017 (16GB)
Software: CTRLR cross platform. MacOS 10.14, Logic Pro 10.5, Audio Unit (native), VST (via BlueCat). Ableton via BlueCat.
Communication: 1 way –> Standalone or DAW Standalone or DAW via VST/Audio Unit to Boss VF-1 for one way control.
This version uses a sysex upload file in the user memory slots to call algorithms.
Featurs: DAW automation. Realtime operation. View all Boss VF-1 parameters for each Algorithm in one screen. Preset data saved and loads within and from DAW.
************************************************************************************
************************************************************************************
Version 2 (Alpha) – Status – In Development. Read blog comments below for progress updates.
Hardware: For Mac and PC tested on a Mac Pro 2010, MacBook Pro 2019, Mac Silicon.
Software: CTRLR and CTRLRX cross platform. MacOS 10.14, Logic Pro 10.5, Audio Unit (native), VST3 (via BlueCat). Cubase and Ableton.
Communication: 2 way –> Standalone or DAW to control Boss VF-1.
<— Boss VF-1 presets into the Standalone/VST3/Audio Unit
User slots are not needed in this version which means you can keep the Boss VF-1 set-up how you like it.
Features: DAW automation. Realtime operation. View all Boss VF-1 parameters for each Algorithm in one screen. Preset data saved and loads within and from DAW. Functions optimised for stability. Load presets from the Boss VF-1 which you can then save in your DAW (provided the DAW contains in-built preset saving).
Bugs:
1. Guitar Multi 1 SDD reports midi error from preset recall. Error message flashes on the Boss VF-1 screen from the standard preset call but the full preset is sent without any problems. I think this could be because I altered paramters and then switched bytes for testing or possibly due to being version 1.0 of the Boss VF-1 hardware.
2. Pedal Page for Bass Multi. If you are on the Boss VF-1 Assign section screen|assign value and then switch the Flanger, Phaser or Chorus mod select via sysex, the VF-1 freezes, needing a turn on/turn off. To prevent this problem, do not be on the Assign value section when switching between Flanger, Phaser, Chorus. No idea why but the VF-1 does not like sysex switching the mods while editing the foot pedals. I guess that before the software, there would not be any easy way of doing this anyhow.
************************************************************************************
Quotes:
X70 Comments: Jayme
i been using the stand alone and it works awesome! this guy really put some time into make a great bit of software!!! thanks again!!!
BuyMeACoffee: Louis
This looks amazing! I love my SE-70 and always worried one day the rare Roland encoder you have to spin like mad for absolutely EVERYTHING will bite the dust, so always wished for some software control.
When it is available, to obtain a copy, add a comment to the thread. I am not charging for the panel but I cannot make promises over functionality, updates and bugs. The panels are made in my free time but I recognise how useful they are. As a bonus, these classic boxes are really cheap rightStarting out can be hard and we all enjoy good music. By making them accessible to a modern workflow, it is also extends the life of these boxes which is great for the environment and but also because they sound great and have some unique fx and approaches. RSS is a good example. Not easy to pull off in a track but when it works, it can be really great. RSS is the psychoacoustic surround sound effect (in stereo) with left/right & up/down pan.
Writing these plugins take time. As you can see from the progress updates below. If you use the plugin and like the plugin, please feel free to send a gift, link/tweet (X), share links to my music or something else that can help. If you have old hardware that you are not using, please consider me. It is appreciated and it gives me chance to build more panels.
Finally: Please note that if you use these plugins, it is purely at your own risk. I write them for myself to enhance my music making experience and I update them when I want a new feature. I only test them on my own equipment (and a few of my musician friends).
For the next update (v2) will aim to include two way communication enhancements.
• Algorithm detection instead of sysex presets.
• Faders and dials load data from the inbuilt presets.
• Data flows – diagrams of how the FX are set up in the algorithm.
• More accurate LCD panel/preset renaming.
However this will be after I release the TC M300, Alesis MidiVerb II and finish work on the Boss SE-70.
[link] Coming soon…
If you like this software, use it regularly and want to support me in my future endeavours, please feel free to see me a gift at buymeacoffee.com by clicking here:
If you find a bug or have some general feedback, you are welcome to let me know by adding a comment to this page (link).
********************UPDATE********************
GUI Look and feel updated to reflect the design colour scheme of the original Boss VF-1.
********************UPDATE********************

********************UPDATE********************

After completing the bulk of the one way communication and GUI design, I’m now working on the Apple Logic Pro (DAW) Audio Unit compatbility. I thought I would run an experiment to see how many parameters I could keep active until the validation app falls over. I am impressed. It can take a lot more than I thought it could.
********************UPDATE********************
After a successful port to Apple Silicon and and Audio Unit in Logic, I created my first update video to showcase my current work.
Due to the unexpected popularity of the TOPD X70 editor for the Boss SE-70 and requests for the TOPD UF-1 editor for the Boss VF-1, I need to get organised! I am now organising the process through a form so that that my inbox can be organised
Your email will come through to my inbox and I will roll off the latest copy. It is important to allow monophreak@outlook.com as a safe address in your mail program because .zip files or links to one drive accounts are typically blocked..
Please remember that many months of hard work has gone into making these editors. You can read about my efforts in the blog pages and comments section. This takes up a lot of my time. If you use one of the editors and find it add values, please support me through a donation via BuyMeACoffee. Support either enables me to get more gear and make more panels or accpet a thanks for a job well done.
Finally, remember to get in touch if you have any ideas to enhance the editors. I have ideas including direct preset save/loading from sysex files, DAW integrations and more. I am open to ideas.
Mailing List
In case I need it, I’m going to upload an image I have made so that I can refer back to the BPM symbols from the VF-1. I think I have this correct. Looking at the VF-1 midi manual, the first symbol starts at 4 Bars aand ends on 1/4.

Progress update: 1st January 2024 started the VF-1 control panel project. Create the AU/VST frame, background, mapped out locations and reviewed the amount of effects I could fit on the screen. Created overall structure.
Progress update: 8th January 2024, wrote the global parameter for settings such as BPM, output.
Progress update: 9th January 2024, wrote the preset system for User 1, User 2, Factory 1, Factory 2.
Progress update: 11th January 2024, created the combo control bank to call the different algorithms, mapped into the panel.
Progress update: 12th January 2024, updated the panel graphic design.
Progress update: 13th – 31st January 2024, wrote faders and dials to control several of the effects inside the algorithms.
Progress update: 2nd February 2024, exported the plugin and tested in Logic.
Progress update: 3rd February 2024, decided on an overhaul. Ditched the tab system. I found artefacts when saving and reloading the CTRLR project. After Googling, panels turned out to be the perfect option. Mapped out panels and wrote LUA script to control panels.
Progress update: 7th February 2024, ported the current set of algorithms to the new plugin.
Progress update: 8th February 2024, wrote LUA to switch off send to midi panel properties so that only the current algorithm/preset will transmit data to the VF-1.
Progress update: 12th February 2024, wrote LUA scripts to control buttons.
Progress update: 20th February 2024, worked out all of the sysex code to control every parameter in every effect, for every algorithm in CTRLR sysex notation, ms ls z5 format.
Progress update: 1st March 2024, started adding in new algorithms. Completed basic testing.
Progress update: 3rd March 2024, made slight changes to the size of the plugin and tested on a 2017 Mac Pro laptop.
Progress update: 6th March 2024, sent to friends for testing/feedback.
Progress update: 13th March 2024, wrote more algorithms.
Progress update: 16th March 2024, wrote more algorithms.
Progress update: Paused project and moved onto SE-70. I paused the project to check the viability of a SE-70 CTRLR panel. I want hardware I can use in a similar fashion to a VST so needed to know if it was worth keeping or re-selling. I found the SE-70 a tough nut to crack but I like the challenge. After making great progress, I moved onto the SE-70 project for a short while but will come back to this one shortly.
Progress update: 28th March 2024, after all the work on the SE-70 panel, I realise there is a better way for the VF-1 CTRLR plugin to run. Therefore, I am going to finish off v1 (which is still really powerful) and then update it to v2 with better two way communication.
Progress update: 28th March 2024, connected Guitar Multi 1 algorithm.
Progress update: 29th March 2024, reached a programming decision point. VF-1 often has a combination of rate and BPM in the same system exclusive code. This can be separated out into two dials/faders for ease of use. Doing this leads to the potential of two sysex presets being sent to the VF-1 when a DAW reloads. I need to write a script to turn off one of the split values while the other is active and possibly loop through this on start-up so values are detected before they are sent to the DAW. My plan is to add an extra value for ‘off’ along the lines of: Called when modulator value changes, run script, IF value = off then disable midi send to the DAW for fader, else keep the midi send active. Technically, if this runs within the panel, it should actually save within the preset. If this is the case, I will not need to loop through these values on start-up. I will then add in these conditions for V2 plugin so that upon algorithm detection, it switches off the unused fader. This will work more efficiently in v2 than v1. For v1, upon preset load – the algorithm variation (such as 1/8, 1/4, 1/2 bar variation) will initially load in for a preview but will need to be manually selected in the GUI to form the final preset. In v2, it will autodetect and switch off the unused fader/dial. The same script will be used across both versions.
As an alternative, I could add a script to toggle between the two faders/dials. This will work if I can wildcard ‘%’/’*’ on part of the string to match the associated modulator. For example, ‘GuitarMulti1_Mod_PH_%’. The advantage of the ‘off’ is that it is a sysex within range +1 for off and saves space but the button is clearer. I will try out both and make a decision.
Progress update: 30th March 2024, successfully written two types of script. A toggle switch to load either the BPM dial or the Hz/Rate fader and a script (2) to de-activate BPM when the fader is active. When the fader is at full height, an extra ‘Off’ option has been added to the very top of the fader and this deactivates the fader, activating the BPM dial. Script 2 is a little less clear although highly function but crucially, it allows more space on a screen and therefore I am going to go with this one for now. I will think about dimming or hiding the dial when the fader is active.
Progress update: 30th March 2024, tested both scripts and both successful. Scripts need to be written to scale up accordingly. For this, the panel(v1)/algorithm(v2) needs to be detected and then all specific modulators need to be identified on the layer panel so that the enable/disable functionality applied to the rate/BPM split sysex. In LUA, tables are used instead of arrays and I need build a table for name, table for value and then key pair them to hopefully feed into my IF conditions.
Progress update: 31st March 2024, worked out the most efficient way to detect the algorithm. Well, that one was a toughie. v1 was more complicated due to the algorithm being connected to the preset. v2 will be 10x easier to write because I intend to get the VF-1 to tell me what algorithm is loaded. I noted a memory efficient solution for when I get to this stage. As of tomorrow, I should hopefully finish off the rest of the code for the rate/bpm activation.
Progress update: 1st April 2024, another real tough day getting my head around LUA. Thankfully, I managed to achieve my goal thanks to one of my oldest and best friend’s guidance and support. Essentially, the problem involved using LUA to build the equivalent of a multidimensional, key paired array but using LUA tables instead. The problem was compounded by the LUA console only outputting the last entry in a variable via a FOR loop, despite processing all of the data (which could be viewed in a table with correct record count). Translating a concept to a different language can be complicated sometimes. I wanted to achieve scalability. One script to cover a function used repeatedly. Anyhow, the main concept is ready and I just need a few more conditions before I start applying this script to the entire plugin.
Progress update: 1st April 2024, I should add that today is an important milestone in that it is the day where all of the key functional components of the panel have been written for v1. From this stage, it will be a case of finishing off adding in the algorithms.
I have a big music project this month and will have to pause the project until next month. I am tempted to bounce out what I have so far (in VST/aU form) as a partially working demo/taster or whether I should wait and release the full project at a later date. If anyone is interested in a taster, please let me know in the bug report/feedback page.
https://monophreak.com/boss-vf-1-ctrlr-au-vst-plugin-bug-report-feedback/
Hi where I can download editors for VF-1 and SE 70 to test?
Hi Koka, it is so nice to receive a comment that isn’t spam! I have a standalone for the SE-70 available and the VF-1 was looking pretty good. I can’t remember where I got with this – I think it was fully DAW to box.
Please let me know if you have a Mac or PC and I’ll compile the latest version.
I’d be interested in trying both out (I’m on Windows). I own both a SE-70 and a VF-1.
Hi Brian, my apologies about the late reply. My MacBook Pro sadly broke down in November due to a bad data cable in the LCD. I had hope’d the problem may have been the backlight cable but it was something bigger. The screen fades to white as soon as I open the lid and then becomes un-useable. It is exactly like in this video: https://www.reddit.com/r/macbookpro/comments/1f4fxiy/screen_advice_gradually_turns_white/
As a result, I have been in-between trying to find a fix, repair quotes and I have been researching the M4 Pro and learning how to build IRs to port my favourite plugin settings over. Sadly, looks like a write-off because I need a whole monitor replacement due to how these LCD panels have the cable attached.
As a positive, Logic’s Impulse Response Utility is fantastic. I really need to add a blog article about this for porting over content to the M4 Pro. I haven’t really got into IRs before now but they are really useful.
Another positive is that, when I am back up and running, I can test everything out on Sequoia. I have put an order in so hopefully will be back up and running in the new year. I have two Hyperbits homework to complete too.
Hi Brian, thank you for the offer of testing on Windows. I have sent an early version your way.
Hi, … I’m on windows and I would like to use the Vf-1 and Se-70 editor. I just got both units and need a editor
Hi, they are really great boxes! I’ll aim to have a look at a Windows port for the X-70 on the weekend.
It’s been a while but I am finally back on the Boss VF-1 project. I think the VF-1 project was the third project I wrote but by far the biggest of the three. After some of the magic of the VF-1, I bought the Boss SE-70 because one near me was going cheap. The Boss SE-70 project took over because the vibe instantly blew me away and it was by far more of a technical challenge than the Boss VF-1. If I was going to learn LUA, I wanted a toughie.
Now that the standalone version of the Boss SE-70 is alive and well, I am going back to the Boss VF-1 project. Going back, I have to say – the VF-1 also has some real charm. While I’m not impressed by the AMP modelling, the other effects are absolutely stellar.
Time wise, I can see I have already completed a lot of work on this. Many of the technical elements have been worked out including panels, knobs and faders for each algorithm with working send functionality from a DAW.
I will need to reshape the GUI. When I worked on the Boss SE-70, I immediately changed the layout to get more in a smaller space and for the panel to fit better on the screen so that when it is contained inside a DAW window, it all fits.
It’s a pain but I spent my day re-shaping the GUI. Next up, I need to look at some of the more advanced design elements from the Boss SE-70 project and see if I can map them into the VF-1 and save myself some time.
After a long day re-shaping everything and building new graphics in jknobman, the graphical user interface (GUI) is taking shape.
The BOSS VF-1 has a tricky colour scheme. Tons of red with white text and black knobs and buttons. To make the panel authentic, I am going to go with this colour scheme because it is distinctive and when I eventually run it alongside the Boss SE-70 in a DAW, it will be clear to see which Boss I am controlling at that time.
Yesterday was a long day. I managed to redesign the LCD, head of the panel and global menu system. I am pleased with the overall look of this section. I then proceeded to start updating modulaters (faders and buttons) on the algorithms section. I think are a lot. I ended up laying the graphics on all of the main on/off switches. setting the midi outputs to 0/1s and realigning all of the titles and LCD panels per algorithm.
For today, I have spent the day replacing the generic sliders and dials with my own design. This includes updating all of the text to match the white on red from the original unit. It looks good.
When completing activities like this, you really realise how deep this box (at 30 bit internal processing) can go. It makes me exciting about using some of these features inside the DAW. Particularly the RSS which is a (from what I beleive) a psycho acoustic, virtual surround sound complete with up/down azimuth controls. It means you can EQ/filter not only front to back and left to right but up and down.
I haven’t seen anything like this particular implementation before and just one of the many gems inside this box.
However, with so many algorithms and so manys layers deep, just sorting out the GUI alone is going to be a long haul but worth it because when it’s set, I can change the skin in a couple of seocnds and refine the look and feel.
Okay, so it’s very late. I have made great progress though and I think that by the end of tomorrow, I’ll have all the GUI elements in place.
I’ll post a screenshot on this page.
This really is a long slog. Thankfully, only 8 more algorithms to go and the v1 project will have a full GUI overlay. I can see there are minor fixes needed with the panning but it will take a moment now that I have a specific theme element that transposes onto every single pan item.
For tomorrow, I hope to start work on the preset switcher code so that either a single user bank or factory bank will be active.
In case I forget, my eventual plan will be to move all of these elements into one single drop down menu to free up space for the assign matrix.
Finally, after a long haul, the graphical elements are in place and now pretty much aligned in their final positions. Only minor alterations will be needed at this stage.
I can now proceed to start programming bytes with combined values (to go beyond a value of 128 from a single midi transmission per knob/fader) and add in elements such as the preset switch, midi lock (to prevent accidental changes to midi) and frequency to bpm switches.
After these steps, I am going to look at the automation mapping. The first edition of the plugin sends data from the panel to the Boss VF-1 only. Since the Boss SE-70 project, I now have an understanding of automation parameters in Logic and will try and create a strategy for adding this into the plugin which extends the functionality from live control (for manually recording changes live) to something managed by the DAW.
I know the problems from the Boss SE-70 project and so will try and overcome this (if possible) from the start.
It’s been a good day. I managed to program in important GUI functionality such as the preset switch, midi lock (to prevent accidental changes to midi) and frequency to BPM fader to dial switches. I’m going to see if I can fix the double bytes in the DAW version of the panel. It will be tough to complete this without two way communication so I may come back and update this when the standalone V2 panel is up and running.
At this stage, I also appreciate the huge chunk of work completed on this project last year. When I started this project, I did not have any idea what it would take to make these panels come alive. Over a year in and I have a strong sense of direction and great understanding what to do in order to build this type of project. I also see why it’s quite rare to see CTRLR panels for areas with multiple algorithms. If I have programmed a synth, it would pretty much be what you see if what you get, a panel (maybe a few layers deep) to control all of the oscillator functions, LFOs, effect and typical features found on a synth. A effect units contains an absolute ton of algorithms which means you are completing the work, many times over. In my opinion, it really highlights the dedication and skill of the Boss/Roland team and why these boxes at current second hand prices, are an absolute bargain. The more I expore the Boss VF-1, the more I can see that this is a gem. While it did not grab me the same way as the Boss SE-70, there are some exceptionally well crafted algorithms inside this box but maybe not where you would expect to find them.
After a long and laborious day, I have managed to get all of the Boss VF-1 parameters inside the Audio Unit/VST. The plugin kept failing the audio unit validation process in Logic and it took a lot of working out as to why this was the case. I found a new program, “pluginval” which gave me a lot more information than the failed message from the audio unit plugin manager from Logic.
I had to make some slight changes to my LUA code and double checked all of the parameter names for automation. I can see that this is going to be another area where this box shines. Using the RSS to pan over the top of my head, down and around using the Azimuth controls looks really good fun. Automation will take this to the next level, enabling consistency in a mix down.
Today, I downloaded the latest CTRLRX and ported to Apple Silicon for my friend to begin initial testing. I was really pleased to see this could be easily ported to Audio Units and VST3 for Apple Intel and Silicon and Windows ARM and Intel.
It’s early days but I was impressed by the stability of the plugin. In case anyone is interested, I have added a video to the bottom of the blog post, showcasing current progress on the project.
After a really solid version 1, of the UF1 editor running in the DAW, I have turned my attentions to version 2. Getting data from the VF-1 was tricky to crack and involved a bit of Googling. I managed to work out the get preset sysex from the midi implementation manual but it just would not take. Eventually, I took the first part of the sysex and typed it into Google. To my surprise, it turned up a post from an old Sounddiver forum archive and involved a situation where a user was trying to load data into Sounddiver and it gave me the answer. In case anyone is interested, the answer (from 24 years ago) is here: https://sounddiver-users.yahoogroups.narkive.com/vpnl8dd1/wolfram-franke-interview and the solution? The Boss VF-1 needs to be on midi write mode in the panel. Yey! this worked like a charm.
In order to avoid the need for this to be on all the time (in cases where the VF-1 encoder is broken or temperamental), I am going to work out all of the algorithm mapping and then enter factory presets from a call menu. There will be an algorithm or user preset toggle. The user preset toggle will pop up a message about the midi write page.
In midi write mode, it would be nice and easy to load a preset, save it into a DAW inbuilt preset menu. On first run, I’ll build a bank of my presets in Logic and then switch to algorithm mode. If I want my preset, I’ll just use the dropdown in Logic.
I can see that this will be a fantastic workflow and as a result, I believe I have cracked the most challenging part of the project.
The next part will be a solid grind. I received a message of 255 bytes from the Boss. This means a lot of midi data which needs to be worked out and mapped into each and everyone of my faders and dials. It is possible that there are more than 255 bytes for some presets but I have not explored this yet.
Analysing the midi will provide me with the information about double byte operators which I can then work out how to handle.
At times like this, I wish I had opted for a simpler project but it will be worth it when I get to automate that fantastic RSS into my music.
I started work on the combo menu system for the user and factory presets yesterday. I already worked out how to call the presets but I wanted to obtain the full algorithm and preset settings to map into the panels. Using CTRLRs checksum system, I wrote the commands using Roland logic to load the preset through a sysex call command to the Boss VF-1 in midi bulk mode. All looks great. I received midi back from the Boss VF-1.
I managed to get nice 255 byte midi chunks back which I will start mapping into the dials and faders. To begin, I need to look at which sections of the midi code call the algorithms.
Over the week, I have been working out the algorithms. This part of the process always takes a long time but I think it will be worth it. While working on the RSS, I decided to dig deeper and pick up a Boss SX-700. Pending how I am feeling, I may either return the the X70 project or work on a new panel for the SX-700.
I now have a good technique for working out the full algorithms for panel mapping. I can see this will take longer than the Boss SE-70 due to how the Boss VF-1 sends out the data. For speed, I think I will look at a temporary development script which calls the current preset buffer routinely following a dial turn. This will provide me with a fast output of the full preset to quickly identify parameters.
I am only four algorithms in at this stage but I am picking up speed. My plan will be to map everything out. Most things look logical at this stage. Output is consistenly 255 bytes on the V1.0 version of the software.
I have already identified key parts of every algorithm including the name, the preset location and the algorithm identifier. As I go on, I’m sure I will work out more and more.
I need to stress, this stage really is a long haul so but if I complete at least an algorithm a day, then I can be ready to start mapping everything into the panels next month. There are no two ways about it, this jobs require dedication. Time to grab a coffee!
Current progress, 6 out of 37 algorithms mapped.
Current progress, 7 out of 37 algorithms mapped. I also picked up a Boss GX-700. My thoughts are if I’m going to work out the Boss SX-700 midi for the RSS, it will may share midi sysex with the GX-700. Therefore, it makes sense to look at them both together.
Another algorithm down. 8 out of 37. Step by step. Little by little, a little becomes a lot.
9 out of 37 algorithms mapped. Feels like a long way to go. This type of software development is definitely not a fast process.
10 out of 37 algorithms mapped. Another small step forward.
11 out of 37 algorithms mapped. Phew! It feels like walking up a hill.
Progress is going well. Lucky 13 down and a few extras such as algorithm id and category id. While mapping out the bytes systematically, I beleive I now have the bytes for algorithm and category. I’m not 100% sure but I think I have it worked out at this stage. I have two algorithms that don’t quite fit the algorithm pattern, Reverb 1 which could have three calls depend on whats active but each are still unique and Delay + Chorus/Speaker Modelling which share the algorithm bytes but different category. Therefore, I’ll use the category as the detemrining factor. It could be an error in my sysex generation though so I will check when working on this specific part.
The other thing I may need to come back to is the preset call from location is 255 bytes but the send from Sysex Librarian gets 410 bytes for an individual patch. If I am missing data then I’ll explore the 255 bytes + 155 bytes to see if there is a better get midi data call.
14 algorithms mapped out and I have written re-usable functions to handle the preset name (including options for editing), the category name and to load in preset on/off switch positions. I worked out how to handle the double byte sysex values containing preset settings.
I’m making great progress. For anyone following along, I have written all of the DAW to VF-1 communication including all functions to handle the core changes to sound. Every algorithm has been mapped in. The current work is on communication from the VF-1 to my software. If all goes well, I intend to be able to click on a user preset or factory preset and beam all of settings into the editor/plugin so that I can quickly store presets I have already built and cherish. I will then save them in my DAWs preset manager and save from here in the future.
I have the v1 version for one way communication (working) and the v2 for two way communication. v1 is very stable and through my experiences of the CTRLR ide, I hope to maintain this stability for the v2 version.
After mapping out all of the algorithms, the next phase of the project is to work out which bytes control which knob or slider. I then work out the relationship between the bytes to calculate the correct value that matches my fader or dial with the one on the VF-1. Thankfully, I have now picked up a lot of experience in this area and provided I have sufficient bytes, it tends to go smoothly. Byte patterns tend to fall into similar types of mathematical equations.
15 out of 37 algorithms mapped. Phew! Steady progress but feels uphill at the moment. Persistence is the key.
Due to coming towards the end of the project, my thoughts are turning to the next box. Thanks to the kind people gifting me coffees, I have looked around at similar Boss boxes in this era (that share similar sysex coding) where I can use my expertise. The candidates are the SX-7000c GX-7000 or GP-100. I should be able to build editors and possible VSTS/AU for these boxes. SX-7000 looks like an amazing box for the enhanced RSS and the GP-100 looks pretty incredible for tone. GX-7000 looks decent for tone and possibly greater opportunity for plugin material. If anyone has a comment, please feel free to share.
I am very thankful to everyone who has gifted me a coffee because it has created a new opportunity. It isn’t why I got into creating the software but it is highly appreciated and I can see how kindness can lead to greater things.
16 out of 37 algorithms mapped. Fantastic night last night.
I programmed in the first algorithm (2 Channel RSS) and it worked a treat. The second algorithm (10 Channel GEQ) was missing bytes. This is something I expected based on Sysex Librarian’s play button sending 410 bytes. After looking at the 155 bytes portion, I noticed the preset bytes were incremented by one value and the checksum decreased by one. As a result, I plugged this into my combo menu and to my surprise, it returned another 255 bytes which had all of the data. To make the function simpler, I spent a bit of time exploring the Librarian message and the manual and eventually found a trigger to call 410 bytes. In relation to handling, this is perfect because I can write a function to check midi length and store the longer 255 bytes as variable one and the shorted 155 bytes as variable two. I can then send the combined output to the main function that calls the algorithm interpreter to load values into the knobs and slider.
This is great news because it is the final missing piece. Other elements are easy to identify but this area was different to the Boss SE-70 and needed some working out.
17 out of 37 algorithms mapped. Yes! managed to re-write the function that loads in the data from a preset and it worked! I used a variable to hold the 255 byte sysex message and another for the 155 byte message. I then run the call to switch preset when the 155 bytes come through being as it is the final part of the message. It worked a treat. I updated the paramter load function to accept two variables. All of the preset parameters from the second message were able to be mapped in and I completed the 10 Channel EQ preset.
Today, I am going to revisit the fader/bpm switch which currently works very well but has a sysex ‘waiting’ call. Although it looks and works great, in the VST/AU version, I can’t see a waiting call would be a good strategy. Therefore, I may change this to an Time/BPM switch before moving onto the next algorithm. From my experience with the X70, I want maximum stability and this will be the best route.
Acoustic Multi ready. I ended up building new switches and functions for the fader/bpm and for the Compressor/Limiter toggles to make everything clean and quick in AU/VST mode. Tomorrow will be a big one, Bass Multi.
Challenging day today. After getting Bass Multi programmed in, I managed to corrupt the project and had to revert to the backup version from yesterday evening. Unfortunately, I lost a night and all work from the next day. These things happen. I was fortunate to save the scripts in an external folder and I could see that I called a function that had a copy/paste end at the beginning, leading into a function which must have caused the corruption. On top of that, after all of the dial spinning, my encoder is now regularly skipping. It won’t be an issue when I have the editor built but just hope it holds out long enough to get it all written. I’m sure it will. Ah well, tomorrow will be a better day.
18 out of 37 algorithms mapped. Back on track after having to rebuild from my backup. the most interesting part of the project today involved finding a way to send a paramter value of 400 from one modulator and using three bytes to unpack a value from the sysex message. I am pleased that I conquered both. This takes me another step closer to the finishing post.
19 algorithms out of 37. Over the half way mark for the mapping process. All of the mapped algorithms then need to be analysed and the bytes worked out. The worked out bytes then get programmed into the algorithm faders and dials, ranges checked and data output tested.
I am currently working on Guitar Multi 1. It feels like a really big hurdle. The Mod FX aspect of the algorithm contains a switch for 11 effects which is pretty cool. However, they share the same byte range which means that any byte can reflect the settings of the active mod. It has to be used in conjunction with the switch settings.
To make it more painful, the active bytes may only produce a sysex output based upon a set of conditions. For for Mod FX, Harmoniser, the Voice switch for mono will activate Pitch and Fine but everything else returns a blank bytes. Switching to Voice Mono (double) or Stereo activates Key and the Harmony 2 fader, level and delay time. It means that while working out, I need to save endless sysex dumps for endless configurations. It is like wading through mud. Time likes this, I do question why I do this. However, looking at the box in this depth tells me exactly while it is worthwhile. It is incredibly deep and versitle openng up a range or uniquely Roland style sounds and FX which are very cool. Half way mark is always a challenge. although in truth, it’s more like 80% at this stage because I have completed all of the DAW to box implementation. Plus, Guitar Multi 1 is the toughest of the algorithms to map. After this, everything else should be less complicated.
I can feel that my poor Boss VF-1 dial is starting to give up. Thanksfully, after the software is written, it will no longer matter as I will not need the encoder anymore. Another reason while this software needs to be written.
20 algorithms out of 37 mapped. I have been working on algorithm Guitar Multi 1 for five days now which is not great for motivation. As a positive, the end is in sight and I only have to test the values, make minor fixes and create several scripts to control the switches. My goal for todays is to move onto Guitar Multi 2 which is lighter. The next big algorithms include Keyboard Muilt and Vocal Multi. I take solace in the fact that Guitar Multi 1 is the largest and the most difficult to map so hopefully the other large multis will not take so long to work out.
21 algorithms out of 37 mapped. Moving forward. A huge leap in the project. I finished the largest algorithm. It took ages because I decided to build individual scripts to control the activation of different features based upon the options selected.
Originally, I had a function that worked well but caused slight hangs in VST/AU form. It cycled through the BPM and Faders to calculate a table of possible options for flicking between the BPM dial and the rate fader. If the value hit beyond a set figure from the byte, it then moved into the BPM value or vice versa. However, it needed a regular look-up on the value change. I reduced this to a user option to switch between BPM and Fader. When presets load, I set the switches to configure correctly. This off loaded 11 look-ups on Guitar Multi 1 (and any other algorithm) which improved the efficiency of the VST/AU and positively impacts on stabilty. On a modern computer, it shouldn’t be a problem but it was causing a delay so there may be something else going on with the IDE and JUCE handling. Therefore, better to go for a reliable experience than something a little more fancy. I did leave a number at the end of each Fader/BPM switch in case I want to come back and investigate this in the futre. Sadly, these decisions, tests and solutions take time which is why Guitar Multi 1 has taken so long. Plus, the clever reusing of bytes for the mod algorithm by Roland took ages to work out and my poor Boss VF-1 dial is really skipping now.
22 algorithms out of 37 mapped. Making really good progress by programming in the mapped bytes to the dials and faders. I finished Isolator last night and I am going to move onto Keyboard Multi. Keyboard Multi and Vocal Multi are the remaining big algorithms. Getting this one bagged will be a large step forward but I imagine it may take me anywhere between one to three days to get this written. I am eager to get some semblance of a life back (away from programming) and therefore, want to rocket through as fast as I can.
23 algorithms out of 37 mapped. I managed to complete about 60%of Keyboard Multi last night which is great news.
24 algorithms out of 37 mapped. Keyboard Multi programmed in and LoFi. Hopefully I will have a faster run with some of the smaller algorithms. The 20 multi-tap looks like the next long mapping. My thoughts are turning their attention to the plugin load feature. When the plugin loads, I want the plugin to either send sysex messages for values from the interface or have a refresh button to do something similar. The reason for this is that when I open and close a project, I want the settings to send automatically so I can pick up where I left off.
I also want to keep the algorithm picker and I intend to load each from a factory reserved area which should work nicely.
The best thing about writing a plugin is that I can really make it work in a way that promotes good workflows to save time. The Boss VF-1 is strange in that you have to put it into read/write mode using the dials to load data but with careful programming, I can bypass this for a lot of functionality and relocate this to the DAW. That way, if the encoder completely goes, it won’t matter.
25 algorithms out of 37 mapped. Mic Simulator programmed in. I feel like I have a good pace and while I’m ploughing through the algorithms, I am thinking about other features such as loading from a sysex file.
Wow, that was a tricky one. To help manage the project (along with my own motivation), I have been working my way through some of the largest algorithms and I got stuck on Rotary Multi for a while there. I solved it but it was an interesting implementation of splits bytes. From the midi implementation manual: https://www.boss.info/global/support/by_product/vf-1/owners_manuals/
On page 29, Rotory Horn Fast is * 01 44 with size 00 00 04 and data 01F4-03E8 (500-1000). Fitting it into a CTRLR modulator was a headache until I noticed the starting point of 500. I handled the 04 with split bytes that worked properly after the value bump. I am amazed at the skill of the Roland Engineers when it comes to this type of thing. Although a bit of a headache, I have pocketed more experience when it comes to Boss/Roland panel building which I’m sure will help in later projects. Kudos to Roland for making the midi implementation manuals availble and so clearly documented.
Had to scratch my head over Speaker Modeling algorithm since it doesn’t exist on my version of the Boss VF-1. From the looks of it, the algorithm was added after the original firmware. Pending the amount of Buy Me A Coffee gifts I get, I may buy a backup to update through the firmwares to cover all features. For now, I’ll add in an algorithm made from the manual which is generally quite straight forward. No idea how to extract the algorithm byte though so I’ll need to look at some presets from the internet in Sysex Librarian.
29 algorithms out of 37 mapped. It is a hard slog but it will be worth it. At times like this, I especially appreciate the kind people who gifted me a coffee, it keeps me motivated because I know that along with myself, there are a good number of people who appreciate the time taken to make this project come alive. Progress wise, I have all of the big algorithms programmed into the dials and faders.
30 algorithms out of 37 mapped. I have been working on the pedal assign system today. It is more complicated than I though. The pedal assign values change based up the elements selected on the panel. For example, with Bass Multi algorithm, you could have COMP or DEFRET selectied, along with EQ or T-Wah or Mod Flanger, Phaser or Chorus. This means that one dial will need to update the values based upon the layout of each switch. I found the best way to handle this is through a function called upon each switch change. Sadly, any algorithm with a switch change will need it’s own function. This will add more time to the project build. I then want to complete the pseudo factory calls (to save switching to read mode if the encoder goes), a guide for read mode and an enhancement to the original algorithm selector.
32 algorithms out of 37 mapped. The end is in sight. I am making good progress with the pedal assign system. The multitude of if this switch is active or that or if this and that… has been mapped. I found a pattern in the algorithm and have a very efficient way of writing the function with the least possible of factors prioritised to get the correct result. As a result, the update is really quick and has not caused any hangs in the CTRL IDE.
All in all, a solid day’s worth of coding. Every possible scenario has been mapped out for the pedal assignment system and all ifs coded in. Being into synths, I hadn’t planned to add in every guitar feature that I need but changed my mind to a large extent because of the amount of guitarists using the TOPD X-70 editor for the Boss SE-70. I can see that these types of features are useful and it makes the new verison of the UF1 more robust and versatile. It wasn’t a major detour for a lot of extra functionality. I am not going to program in the pedal lower and up range limits because I can’t see why this is very useful in relation to the amount of work it involves but may change my mind. I will leave it open to be programmed in later on and I will program in pretty much every other pedal feature so that effects can be mapped to compatible foot pedals.
33 algorithms out of 37 mapped. Patterns, patterns, patterns. The full byte map is coming into view. I believe I can jump in speed for the preset based Master Level, BPM and Foot Level settings through a distinct pattern in the bytes.
34 algorithms out of 37 mapped. Through persistence, , the huge task of mapping all of the algorithm bytes is almost complete. In addition, I have finished mapping all of the preset master level, bpm rate and foot level options for all of the algorithms. My next step will be to program the update commands for the knobs and faders for the pedal settings from the preset. All of the potential conditions have been mapped against the sysex, verified by the front facia of the VF-1’s led readout. So now it’s just a case of working out the byte pattern, deriving the value for the dials and faders and then loading it into the panel each time a preset is selected.
I’ll be pleased to get this chunk of work overwith because it is a grind. The next stage will be writing scripts to control some fantastic enhancements to suit my workflow and open up the box more. This is much more exciting than working out bytes.
35 algorithms out of 37 mapped. I managed to work out the bytes for the pedal screen from the first part of the 255 byte sysex message. Next step will be to program them in.
Amazing! Almost there! Cheers Phil!
Thank you for your kind words and support Phil. It is indeed almost there! The last few parts involve an algorithm switch for one way comms mode, single sysex file browser (mostly writen) and a menu switch to load in the factory presets without the need for read/write mode to be activated. All of these are much shorter tasks than all of those that have come before and they already have a chunk of code written for them.
36 algorithms out of 37 mapped and great progress. I have nearly completed the algorithm reading part of the project.
I programmed in all of the pedal mapping with the exception of target min and max ranges but I left a space in the GUI in case there is demand for this feature. I coded in all of the source min and max ranges though since this could override the target values anyhow. My reasoning behind all of this is connected to the way in which the target values change to represent the associated dial, fader and values.. It is a lot of scripting for a relatively small gain. If however, I get suitable requests, I may revisit this but for now, I have my eyes set on a SX-700, GX-700 or GP-100 project. I may even venture into Lexicon and build a LX5 if I win one in an auction. I am very thankful for the buy me a coffee gifts because it opens up more possibilities.
37 algorithms out of 37 mapped! Hooray! I also completed the sysex patch upload from file! Double hooray! I can see this feature would be really useful for sharing presets if the DAW does not have it’s own preset editor.
This is really useful. I could store the factory presets into a series of sysex strings and load them in via the combo box while also sending the patch change to the VF-1. That way, the VF-1 does not need to be set to read/write mode but both would be in sync for making edits. For this, I may build a v1 and v1.2/3 toggle so that the original presets and the updates presets containing the new speaker algorithm can be accessed.
If I’m feeling brave, I may update my VF-1 to the V1.3 firmware. I have read a few horror stories about bricked boxes in the past so I will need to think about this. The positive is that I would be able to make a comprehensive editor/plugin which operates 100% across versions. I could see if I could track down a VF-1 or maybe something could send me a dump of their VF-1 if they have v1.2 or v1.3. I am sure I can work this out. My own upgrade would depend on depend on the coffees. If I do, I’ll record it for YouTube and aim to use something more modern to make the update.
Oh, I forgot to mention that the sysex patch utility was programmed in a way that it’s easy to apply to the TOPD X-70 editor for the Boss SE-70 which means this will get another update in the future.
I worked out how to load a .syx file into the TOPD UF-1 last night and translate the values to the algorithm panel. I then adapted the memoryblock() code to the factory preset combo utility so that when a factory setting loads, all of the parameters for all dials and faders loads into the VF-1 so can see exactly how they are set and can get straight into editing. I decided to go for this route for speed. Without following this, I’d need to switch the Boss VF-1 into read/write mode everytime I want to use it and if the encoder goes, well, I’m stuffed and part of my goal was to make this run if the encoder breaks. It means broken or jumpy VF-1s can be brought back to life and hopefully help the environment by saving on some landfil. It was slightly tricky in that the file had something like 598 bytes but I needed to extract 255 bytes for the first 2/3s of the panel and 155 bytes for the second. This left over some bytes that were not used for the presets. I have to collect about 170 more sysex commands from the VF-1 and then this section will be ready. Interestingly, the VF-1 transmitted a few over in a malformed format. I remember reading about the version updates and recall from one website, that the updates solved this type of thing. Because I’m working on v1 and don’t want to risk an update until the end of the project, I will most likely copy the the final part of sysex code from another setting and then calculate the checksum to make a functional sysex message. There may be tiny differences so I’ll complete a visual check between the two and may even just zero out some sysex bytes based upon my sysex maps.
During the sysex dump, it was absolutely fantastic to see the TOPD VF-1 visually cycle through all of the presets, mapping in all dials and faders as the sysex information downloaded from the VF-1 to SysEx Librarian. As the download ran, 200 presets cycled through the UF-1 at rapid speed.
My aim for today is to try and get as many of the 170 factory sysex strings programmed into my combo box as possible. Then, I think the only part to complete will be the algorithm selection drop down menu when I have a new feature which enables me to select algorithms directly from a combo box, mirrored by the Boss VF-1, similar to the factory preset code, so that I do not have to remember a preset associated with a particular algorithm, I can just chose the algorithm. I’m building this because it’s a workflow thing. I am also eager to work on my next three tracks and when I do, I want to be about to quickly chose an algorithm and run from within Logic Pro for automation. For example, RSS. I have some plans to use the RSS Panner on parallel to get some very cool movement in y next track. For these types of things, workflow is very important and I have had lots of thoughts about how I want to use this with my DAW which sometimes means building features that do not exist.
In case I forget, I need to check the rate to bpm switches through extreme test boundaries (upper most and lowest levels) before changes between the two.
The final stagees involve adding in snippets of code to prevent indexing of some scripts upon start-up, checks on the panels sending messages to the VF-1 and then compiling for the first alpha release. Due to the size of the project, there will be some bugs because there are a ridiculous amount of variables on this project but I have written the code in an object orientated fashion with descrete functions which basically means, a bit of code to control a specific part of the panel or algorithm. This makes bug fixing quick and easy.
The first 100 factory settings have been programmed into the combo via sysex to memoryblock(). The settings that had a corrupt checksum and were malformed include the following: Jet Flanger, 3 Voice-Lead, Mellow Attack, Step Phaser, Spacy Lead, Hi Gain MS, Big Lead and Vocal Duo. I’m going to try the following, re-save to the user block and re-import the sysex to see if I get the same issue. Otherwise it’s a case of looking at the values and adding them to a sysex string manually based upon my mapped algorithm data.
Oh nice! That fixed it. Looks like the v1.00 patch dump utility from the VF-1 to Sysex Librarian is prone to errors. I will program some checks to the sysex byte length equal 255 and 155 byte lengths to prevent errors messages on the VF-1 and paramater mapping issues when loading from the box.
200 factory patches transfered to the combo menu. Algorithm combo tomorrow then I have to work on the GUI a little.
Okay, my own workflow algorithm select system has been a toughie but I feel it is important to acheive this because of my own workflow. It will make things easier and save me from having to remember all of the algorithms containing a specific feature I’m looking for. For example, there are many flavours and chains of flanger and I’d rather be able to group them together in a list and cycle through a small clump to work out the best fit. To make my virtual sysex preset load a set of panel software data marry to the Boss VF-1 settings on the hardware, I have needed to build the sysex name, run a script to switch the algorithm into the correct type (reseting to the VF-1 default), export this sysex, store into the memoryblock() section of the combo, call the algorithm command, load the virtual sysex and then run sysex commands to update the patch to make the preset sit where I want. Phew! Cracked the workflow and built the sysex chains. Just need to export from the VF-1 and then complete the combo programming. It’s late but I know what I want to acheive with this so will hopefully work a miracle in the last few hours before sleep.
The algorithm menu is working. A command is successfully being sent to the VF-1 to change the algorithm from a combo box, containing an embedded sysex string matching the default algorithm setting from the VF-1 so the software and hardware align. The next stage is to work on the preset changes for all of my algorithm quick starts, created during the version 1 build of the UF-1 panel.
This will include things like a function to look-up the the preset name from the embedded sysex and transmit it back to the Boss VF-1. I will create additional sysex sends over so that the VF-1 updates to suit my preset changes. I’m not sure if I should embed this inside the large sysex setting for the algorithm and then send to the VF-1 or make a change in the panel after it has all loaded and then the change transmit to the VF-1 as the panel updates. I will cross this bridge when I come to it.
After this part, I have to make some small GUI changes, check the rate and bpm switches, check the foot pedal assignments on some of the larger algorithms, test the algorithm dials, faders and then I am finally ready to launch the first alpha version for testing. Almost there! I’m so close now. It is a great feeling.
The second part of the algorithm menu is now working. After the combo box switches preset, a sysex command sends the name to the VF-1 to keep sync. To make this work, I created a function to live update the preset name on the front of the VF-1. You can type into the keyboard and after pressing enter, it beams over live. It was a bit of a pain having to split the 13 text entry bytes from CTRLR into 26 bytes to handle the separate ms and ls part of the sysex. I then had to generate a checksum and map it to just before the end of the sysex chain. Experience from the Boss SE-70 project was invaluable here. Each day, I’m getting closer to launch time.
My algorithm presets menu is coming along. I decided to take the approach of taking the default sysex for the algorithm, making an update on the VF-1 to rebuild the sysex that will be loaded into the menu. I then run a sysex command change from the algorithm select so that they match on the panel and VF-1. It means I do not need to run two sets of commands – update the panel and then the vf-1. I can load a panel already set how I want and then send the instruction set. It’s only marginal gains but I have built the project with as gains as possible to make it as efficient as I can. For example, long IF statements start with the smallest parameter changes then use elseifs so that they stop when the value is reached.
I lost a few presets at the end for Space Eco 201 and Vocoder. I’ll leave these generic until I can find them again which means the last few at the end will go out the same until a future update.
Ah that’s a pain. After making all of the saves directly to the VF-1, they are not recalling properly from the VF-1. For example, change the Isolater Chorus switch with 1 bar as a default, will not recall properly. Some work, some do not. I think I will have to consider both options or maybe update the Sussex directly from my mapping chart and recalculate the checksum. This is one area where I may release the panel and the tidy up later.
Okay… so after a quick test, the solution is to load the default sysex algorithm as set by the VF-1 change and then update the modulator value to reflect the preset. By updating the modulator value, it triggers the sysex send anyhow which keeps them in sync. Phew! Glad I cracked it.
Algorithm preset menu written and the GUI slighly reshaped to get the algorithm menu into the top right selection area. I halved the user preset menus since I have not written anything to update the text in the combo box. That in itself is a new function that I may write in a future update but for now, it will be useful for loading in presets from the box which can then be stored in a DAW such as Logic.
For tomorrow, I will update the led selectors to include one more led from the gui, specifically for the algorithm selection. I will then start on the final GUI element which will be a question mark button providing a short guide on how to enter read mode from the VF-1 front panel. I think this is important because I tend to forget things like this after not using it in a while and as I’m writing this for my workflow and speed, it’s a good idea to add this in.
Updated the preset menu system to activate the led switches and the combo box disabled method. I also managed to update the save button and the [ i ] info button for the Boss VF-1 read/write mode guide. On top, I couldn’t help myself – with the Lexicon LXP-5 on the way, I started work on a new editor which can be found here: https://monophreak.com/unicorn-lsp-5-editor-for-lexicon-lxp-5/ The new editor has been written in a way that other boxes such as a LXP-1 and LXP-15 can slot in. One of the key reasons I appreciate the free coffee gifts (along with the fact that it’s really nice that people show their appreciation for my work which does lift my spirits my the projects are long and tough), it also opens up new opportunities.
I meticlously built some Boss VF-1 diagrams for the guide detailing how to place the Boss VF-1 into a mode which can send out sysex for the TOPD to read from. I completed work on the guide section of the panel complete with button. It looks good. I’m going to add the diagrams to the main blog page because I like how they look.
I have been working through the BPM and Rate switches. In hindsight, I should have build added a prefix, delay and then the 3-tap or single so it appears in a better order as a VST/AU. This is something I’ll come back to in a later release. I also need to fix a switch on preset load so that if 3 Tap or Single is loaded, it deactivates one or the other. My code works in live mode but something is odd if the rate is equal to or below 1800ms. A trigger is hitting to not grey out the single tap options. It is minor so will aim to fix after release.
Okay… down to the final 3 tasks before I start the VST/AU clean-up.
1) Clean up some of the v1 code including a few layers and the layer hide function/about button toggle.
2) Clean up the pedal if condition load order.
3) Check the dial and fader sends from the algorithm.
There may be a few clean up tasks after that such as prevention of script loading or indexing in the DAW when it loads.