Yes, I’ll have to check if the restriction check (that worked fine in FW2) still works in FW3.
2 Likes
Hej @joris.roling and @martin,
FYI: I just tested the new Moss Bitwig Preset and the communication there also changes colors and names of my other presets… So it seems to be a FW3 thing? Also checked, if communication in my presets over the not used MIDI Device 2 helps next to the Bitwig presets communication over MIDI 1 and CTRL. It doesn’t.
2 Likes
Are you saying that elements in other presets are somehow overwritten? I cannot reproduce that.
Can you please give some more details what you are doing and what is changed?
EDIT: Oh, I see what you mean. It updates when something changes in Bitwig. Will fix it!
4 Likes
The DrivenByMoss fix is online. See here: DrivenByMoss for Bitwig and Reaper - #11 by martin
2 Likes
Greetings. I’m trying to figure out if what I want to do is possible as I’ve never fully understood Bitwig’s approach to mapping. And I’m trying to figure out if Electra One would work for me.
Let’s say I’m running an instance of a 3rd party VST synth in Bitwig and want it mapped to my Electra One in an order that I determine. Let’s say Repro-5 which is on one level quite simple, but has dozens of parameters. I want access to almost all the parameters on my Electra One, but ordered in a logical way that I decide.
Do I have to create a whole bunch of screens of 8 macros and then map them to the Electra One?
Or am I better off creating a preset for Electra One that maps to the instrument and then somehow saving it with the VST file in Bitwig so that any time I open it, it’s able to be addressed? I would then also have a separate preset on the Electra One and switch between that and other presets address to other instruments in the same set?
In Live, I know it’s all per-project, so I do all the mappings I want for a project and “save as” which is way easier on the mapping end. But of course that means I always have to have a default project that contains all the mappings I want at any time.
Thank you.
If you use DrivenbyMoss, there are dynamic device screens so once you create remote controls the bitwig preset will be able to see them automatically. The preset is dynamic so a bunch of things get handled this way.
If you watch the video this should be pretty clear.
Note that this is all very specific to the preset and bitwig plugin. If you make your own traditional Electra preset you would have a lot of manual mapping to do.
As dstengle already wrote, you have both options. Using the 8 remote control parameters (called “macros” in Ableton) is the easier way to setup than having to implement an Electra One template.
Creating a Electra One template has the advantage that you can see more parameters at once and create a nicer layout (e.g. with Envelopes).
With remote controls you do not need to map them to the Electra One, this is done automatically. Furthermore, you can choose to create remote control pages which are global to all projects or on a per project basis (or combine both and/or put them in a template).
I did a tutorial video about the topic some time ago: Using Bitwig Remote Control Pages, Macros and Poly Aftertouch - YouTube
1 Like
Thank you @moss . One question–can you have multiple pages of 8 remote controls per device in your script, or only 8 controls per device? I know Bitwig allows multiple pages.
I’ll take a look at the video. Edit: I watched the video and I see that multiple pages show up so I just select them. Thanks for your great work on the Electra One!
2 Likes
Hej @joris.roling,
I wanted to take a look at your Bitwig script again and learn a more about the implementation on the Electra part and Bitwig part…
Maybe tinker it in the direction of using more than 8 parameters of Bitwig remote pages simultaneously like here:
But your Github repro is down… Is the controller extension still available somewhere?
Best,
Björn
Thanks a lot Joris!!
Still love the 14bit MIDI and simplicity of your script 
Hi @martin
We need your help:
Current Preset (mk1) vs Visible Preset (mk2)
The Bitwig Control script I once wrote still seems to have some fans (due to its 14 bit resolution amongs others) and on the Electra One mk2 we see a problem:
-
The Bitwig Control script (the actual ‘client’) there is a mechanism in place to ‘know’ of a certain preset is active, and if so, it will use rather ‘destructive’ instructions which will ‘kill’ any preset except the Bitwig Electra One preset. It does this by requestion a ‘Preset Request’ sysex, and awaiting a ‘Preset Response’. In this response (on mk1) a ‘preset’ field would tell if the currect preset was active, and would fire all kinds of ‘visible on/of’ & ‘color’ & ‘name’ instructions. Stuff that would mutate any other preset. When a preset was switched, it would be signaled via sysex, and the above sysex dialog would be started allover (possible ending up in a ‘non-active’ state). All was good, up until Electra One mk2
-
Possibly due to Electra One mk2 has this concept of all presets in one bank being active at the same time, there is no more ‘current’ preset, and I see it NOT being part of the ‘Preset Response’ anymore. Currently, if that is the case (that field is missing), I continue being ‘active’ and so, if the preset is actually some other than my Bitwig Control preset, will mutate it, and makes things unworkable.
Is there a newer concept with Electra One mk2 as ‘visible preset’, I could track, and as such, behave nicely? If so, could you point me to that mechanism?
Cheers,
Joris
1 Like
Hej @joris.roling and @martin
Just one more note: As I’m still on MK1, the problem is not the hardware but it seems to be with the firmware 3.0 and the check method in Joris script… has something changed with FW3.0 to get the active preset?
Hope to get to the cause of it 
After some tinkering @joris.roling script (next to watching Moss’ great Bitwig API videos 
), I’m stuck with my modest knowledge in parsing the SysEx dumps from the Electra that Get an application information :
0xF0 0x00 0x21 0x45 0x02 0x7C 0xF7
It is used by Joris’ script to identify the active preset. First the recieived Data is parsed from the SysEx part into a JSON array and the output for Electra FW 2.2 looks like documented:
When I use the Electra FW 3.2.2, the resulting JSON for the same SysEX recieved shows no values of the active preset…
The SysEX data part / JSON array seems not to have any preset info? Is that a bug on the Electra side or am I parsing it wrong or do I have to use another SysEX command in FW 3+?
Thanks in advance for any hints and sorry, if I ask trivial stuff - just getting into coding again…
Could it be that the response JSON strings in the preset need to be added/updated?
I know that Martin said that in earlier OS versions, the active preset could see the incoming sysex even if there was no response header.
1 Like
Just to be clear, the script @studiobischof is ‘messing’ with, is on the Bitwig Control side of things, that is: outside the Electra One, as a ‘client’ so to say.
Ja, thanks @oldgearguy, the preset on the Electra has no Lua code next to requesting a patch on start. All the updating of new patch controls is managed via SysEx commands to the Electra, coming from the Bitwig Javascript. And the Electra sends out SysEx automatically to this script on switching pages / presets but with FW3 this SysEx now seems to be different…