Many many thanks. Took me about 10 minutes of using this to decide to donate! Solved some major headaches for me being able to map nrpns!
One observation and a couple of questions...
1. I noticed when I selected "Track selection" from the drop down the mixer would auto select as expected but not the track list. On the other hand when I mapped to the track select action both items scrolled into view.
With regards to the action list item, I saw somewhere on this thread or maybe it was another one about finding something in the long list of actions but when I went back to look for I could not locate it (I'm cross-eyed from reading posts). Are there any options to make it easier to find the action I'm looking for?
2. What is the difference between trigger and absolute? (I guess I don't understand what invoke means)
Thank you again... This is absolutely a tremendous help!
1. I noticed when I selected "Track selection" from the drop down the mixer would auto select as expected but not the track list. On the other hand when I mapped to the track select action both items scrolled into view.
I suppose it makes sense to add this automatic mixer scrolling to the "Track selection" target. If noone objects, I will add it (without making it configurable).
Quote:
Originally Posted by Steviebone
With regards to the action list item, I saw somewhere on this thread or maybe it was another one about finding something in the long list of actions but when I went back to look for I could not locate it (I'm cross-eyed from reading posts). Are there any options to make it easier to find the action I'm looking for?
The only alternative right now is to "learn" the action by executing it. Doesn't work with all actions though.
Quote:
Originally Posted by Steviebone
2. What is the difference between trigger and absolute? (I guess I don't understand what invoke means)
"Invoke" means something like "execute". The actual difference between "trigger" and "absolute" is that with "trigger", incoming zero values (like for example when you release a button or a key) are ignored.
Here's what this means in practice: The reason for having two different invocation types (in addition to "relative") is that there are different kinds of actions in REAPER. Most of them are trigger-type actions like for example "Reset all MIDI devices": You just execute them and done. For this kind of actions you usually would choose invocation type "trigger". If you would choose "absolute", releasing the button would execute the action again - which is probably not what you want.
But there are also on/off actions and most importantly "MIDI CC/OSC" actions. They are more like an automation parameter in that they have a value range. Just take "View: Zoom horizontally" as an example. Sending a zero to this action probably means zooming out very much. Sending the maximum value to this action would zoom in very much. And then there are many values inbetween. You would usually choose a knob or fader to control this kind of actions ... and you should choose invocation type "absolute" because zero-values do matter.
I'll have to try and roll back a version or two for now, if I can find old installers.
Can anyone reproduce?
EDIT: OK this is weird. I rolled back to v1.5.0 and that didn't work either. So I tried v1.0.0 which can't see JSFX parameters and crashes REAPER when trying to learn them. I'm sure ReaLearn used to work fine with JSFX...
EDIT2: *Success* Got ReaLearn 1.0.0 working with JSFX (rel1 mode) in REAPER 5.77 (ReaLearn 1.6.1 does not work with JSFX in REAPER 5.77)
EDIT3: ReaLearn 1.6.1/REAPER 5.93 'works' with JSFX in rel1 mode when step size min is >50% - Works, but is kind of useless.
I made a small donation, just to show my support. I'll probably buy Playtime down the line too, but right now I try to keep my focus on setting up all my midi controllers for mixing and sound design
I also had a cool idea of a feature for "grouped plugin focus", which means instead of having either "track selected" or "fx in focus", you categorize different groups and control what fx are handled together by different groups. So if one fx from the group is in focus you are controlling all the plugins in that group at the same time. Whenever I click on one of the effects in a particular group all of the fxs are made active.
This would make it possible to control more than one plugin at a time without having overlaps.
The purpose of this would be to set different groups for different tasks like, doing compression, EQ'ing, wet effects or sound design. Right now I have 30 knobs from 4 different controllers available. When I'm creating sounds with Omnisphere I'd have everyone of them control only that plugin, but I don't need nearly as many knobs for my EQ, so I might deploy all of those knobs on 3 different EQs or have them control my comps too and make my own channel strip out of 3 different types of plugins.
I hope I made myself clear, if not please let me know.
ReaLearn + Automation envelope on Latch/Write/Touch = Problems
HellO!
I'm curious how you guys would tackle this or if you've experienced similar issue or if this is a bug with ReaLearn :
In a live performance environnement, where I record some midi & audio tracks on the fly (using Playtime btw! Yeah !!), I'd also want to record the automation of different FX i'm throwing in the mix (Filters, delay, etc) and ALSO, switching between different instance of Vst's on the same track (to have for example 2 different piano or synth sounds during the song)
To be able to record and hear those transitition after - during playback - my tracks need to be armed and automation mode switched to either Latch/write/touch. This causes trouble with my controller light feedback/mapping under ReaLearn. Specially when Bypassing FX.
Typical track setup is this :
Fx chain loaded with 4 Vsts with their "bypass checkbox" mapped to a specific pad.
When the pad is lit up, I know the vst is active and vice versa.
When envelopes are in read mode, this works like a charm and the bypass/light feedback reacts accordingly! That is : Pad lit up = Vst Activated (i get sound) ...VS... Dark pad = bypassed, no sound. That way I can make sure only 1 vst is playing at any given time on that track
BUT, in Latch/write/touch mode either ReaLearn/Reaper/launchpad gets confused and pads start behaving in a REVERSED way : Pads are lit up when Vst gets bypassed (no sound, envelope at 100%) and when pressed again, Pad go dark but Vst gets activated and now it's confusiiiiiiiing.
In my projects I have certain tracks that need to be soloed whenever another track is soloed. These tracks are associated with a group and this function works normally when ever I initiate the solo from within reaper or my Mackie console. Whenever I use the mouse, keyboard shortcut or press the solo button on the associated Mackie controller the slave track responds as expected. However, whenever I initiate the solo from an external control that has been mapped through Realearn, only the master is activated and the slave remains solo off.
I could've sworn I had this working from the external controller although now I'm not sure.
Note: The first thing I did this morning was to install the SWS extension. Immediately thereafter I noticed that the solo function was not working as expected. I couldn't find an easy way to uninstall SWS extension (and that's not something I would want to do anyway). But perhaps if someone can tell me how to do that I could verify if that is in fact causing some kind of interference with this function.
I am having the same issue as explained at that link. If I change the track a controller is assigned to (move or copy or reinstantiate ReaLearn on a different track but try to use the same controller as previously used, then reaper will crash - every time. Does not matter whether used track FX or input FX, the results are exactly the same. I love the concept of this plugin, and desperately want it to work given reaper cannot do midi learn for mixer objects. Thanks.
Something is going on with ReaLearn on my setup. It crashes Reaper everytime I run it. Even if I set it as dedicated process. No way to run it anymore.
I was doing some cleaning with MIDI Devices, and maybe ReaLearn is waiting for MIDI device that is not there anymore.
How do I reset it, so that it loads with default settings?
Testing a bit more. ReaLearn is not working here on Reaper 5.94.
It works on 5.93 (although loads really slowly). But on 5.94 on my system it crashes Reaper every time it is loaded.
OK, I tried with 32bit version, but it gets blacklisted by Reaper. It doesn't even appear on plugin list, and it gets disabled in reaper-vstplugins64.ini.
Back to 64bit version, it appears on the list, but crashes Reaper 100% on my system.
Must be something changed with Reaper 5.94.
I'll have to try and roll back a version or two for now, if I can find old installers.
Can anyone reproduce?
EDIT: OK this is weird. I rolled back to v1.5.0 and that didn't work either. So I tried v1.0.0 which can't see JSFX parameters and crashes REAPER when trying to learn them. I'm sure ReaLearn used to work fine with JSFX...
EDIT2: *Success* Got ReaLearn 1.0.0 working with JSFX (rel1 mode) in REAPER 5.77 (ReaLearn 1.6.1 does not work with JSFX in REAPER 5.77)
EDIT3: ReaLearn 1.6.1/REAPER 5.93 'works' with JSFX in rel1 mode when step size min is >50% - Works, but is kind of useless.
Please send me the RPP file (to info@helgoboss.org). What doesn't work exactly? Which JSFX in particular?
As it exists currently, ReaLearn mappings are tied to the order of the FX instance within the chain and using <selected> while changing FX order leads to some undesirable behavior. Please see the video:
1) Use one global instance of ReaLearn
2) If the mapped plugin exists on the selected track, then control it
3) Otherwise, do nothing with that mapping until the mapped plugin is added to the selected track or another track is selected.
I'm fine with being limited to one instance of each plugin per track if that's necessary. This is just how I want to use ReaLearn. I realize other people have other needs, but it would be very nice if ReaLearn can be adapted to function this way. Thanks.
its possible to this integrate with reaper v6?
this will be a killer feature
i would definitly pay more for this!
I'm not sure if it would be a good idea to do so, mainly because ReaLearn internally uses different programming styles than REAPER itself. For instance, it makes use of high-level libraries such as the C++ standard library or RxCpp. On the one hand, those programming styles make it much easier for me to write and maintain ReaLearn. Infact, without them I wouldn't even have bothered to write it at all. On the other hand, you can see the consequence of that in the increased size of the ReaLearn DLL (or bundle size on OS X). AFAIK REAPER itself uses more low-level-style coding. I'm glad the REAPER developers do it that way because it gives us a super efficient DAW in just a few MBs. As such it's a perfect core/platform for plug-ins building on it.
Can I ask you what you would expect from a ReaLearn that's integrated into REAPER compared to what ReaLearn is already now? Just the convenience of not having to run another installer? Let me know. Maybe there are other ways to tackle this than shipping ReaLearn with REAPER.
Quote:
Originally Posted by ErBird
As it exists currently, ReaLearn mappings are tied to the order of the FX instance within the chain and using <selected> while changing FX order leads to some undesirable behavior. Please see the video:
1) Use one global instance of ReaLearn
2) If the mapped plugin exists on the selected track, then control it
3) Otherwise, do nothing with that mapping until the mapped plugin is added to the selected track or another track is selected.
I'm fine with being limited to one instance of each plugin per track if that's necessary. This is just how I want to use ReaLearn. I realize other people have other needs, but it would be very nice if ReaLearn can be adapted to function this way. Thanks.
I can see what you mean. It's also a bit inconsistent right now.
- I think when you choose "<This>", "<Master track>" or a particular track (so everything except "<Selected>") as target FX track, things work as they should: Whenever you reorder the target FX within the chain, ReaLearn picks up that reordering. Actually ReaLearn neither refers to the FX position nor to the FX name, it refers to a unique and stable FX ID.
- Things get funny as soon as you choose "<Selected>". Whenever you reorder the target FX on the currently selected track, ReaLearn picks up the reordering. But when you reorder FX on an unselected track, it doesn't. I think that ReaLearn should just ignore the reordering when using "<Selected>" and instead refer to the FX either using its position or its name (as you suggest). Have to think about which makes sense. I guess both are valid options, so maybe I will make it configurable.
Originally Posted by sievr its possible to this integrate with reaper v6?
this will be a killer feature
i would definitly pay more for this!
Quote:
Originally Posted by helgoboss
Can I ask you what you would expect from a ReaLearn that's integrated into REAPER compared to what ReaLearn is already now? Just the convenience of not having to run another installer? Let me know. Maybe there are other ways to tackle this than shipping ReaLearn with REAPER.
Related to sievr's post, I am thinking awareness of this plugin's existence is lacking, for example it took me ages and many searches to stumble across it by accident and only because I refused to give up in the face of loads of comments elsewhere saying "it can't be done". Possibly a little more about "advertising" of realearn rather than "integration in source" if that makes sense. All my searches for ages came up with some PC-only 2010 plugin along with instructions on how to hack it to get it to work on Mac - persistence paid off in finding this little beastie.
What I have grown to like about this plugin is something not available to any other DAW - for example with limited faders (e.g. 8) you can choose tracks in any order for those 8 faders to control.
I also suspect that awareness of the difference between CC as a control message and the more advanced concepts of what is needed in a "control surface" are largely misunderstood / not known by end-users, and some people might be expecting a control-surface ability from a much more simplistic MIDI CC message without realising the different complexities underlying each. Your plugin holds a unique place in DAWs in my perspective. Where control surfaces can be (and should be) banked in groups of faders (typically 8), yours can be freely assigned (although the option to bank groups will always be handy). This freely assignable approach steps away from a control surface into a different place that is useful in other ways.
These thoughts are just that, thoughts. Lovely work Ben.
Changes:
#134 Added possibility to select '<Any>' as source note, CC and channel
#157 Improved usability by always displaying track/FX/parameter positions and MIDI device IDs in labels and dropdowns
#150 Improved usability by ignoring FX reordering and removal whenever '<Selected>' is chosen for track targets. That just makes more sense. So there's not such a tight connection to the FX anymore in this case. It will use whatever FX is at the position and if there is none it won't do anything.
#139 Improved usability by automatically scrolling mixer when selecting track via 'Track selection' target
#149 Improved usability by also displaying disconnected MIDI devices in REAPER >= 5.94 (if you think there are so many now that it gets confusing, it's time to clean up in REAPER => Preferences => Audio => MIDI Devices by using the 'Forget device' operation
#140 Improved processing by completely disabling feedback and control (even if coming from direct hardware device) whenever ReaLearn FX is disabled
#143 Improved processing by disabling 'MIDI thru' if MIDI control input comes directly from a hardware device (so ReaLearn will now only forward MIDI messages to its FX output if they come from its FX input)
#147 Improved processing by reliably detecting if FX change occurred on input FX chain or normal FX chain for REAPER >= 5.95pre1
#148 Improved performance in some cases by using new function in REAPER >= 5.95pre1 to look up the project for a given track
#155 Improved performance in some cases by never creating an undo point when arming/disarming ReaLearn track
#133 Improved usability by adding a remark to targets 'Track FX enable' and 'Track mute' that they don't provide feedback from automation changes (currently not possible, capability needs to be added on REAPER side)
#151 Fixed non-working relative mode for probably most JS FX, also fixed detection of discrete FX parameters
#142 Fixed crash when using a fader after having removed a ReaLearn instance with direct hardware device input
#144 Fixed OS X crash related to MIDI device API changes in REAPER 5.94 (also fixed in REAPER 5.941)
#145 Fixed confusing OS X MIDI device dropdown behavior if device is not known by explicitly displaying a temporary entry '<Unknown>' instead of just displaying the first entry in the dropdown
Where is the installer putting the dll file? (64 bit Windows)
I'll be damned if I can find it. I had installed 1.6.1 a few weeks ago, and (must have) copied the dll to where my VSTs are - but I can't remember.
In the meantime - I'll just grab the portable zip file, and install it manually
ReaLearn installer extends your REAPER VST path automatically, it should just work (assuming it's a normal aka non-portable REAPER installation). Doesn't it? It puts it to "C:\Program Files\ReaLearn\VstPlugins". But really, better don't mess with the paths, I put it there for a reason (32-bit/64-bit conflicts etc.). However, if you have a portable REAPER you should use the portable ReaLearn ZIP file.
Sorry, I have a little problem with "FX must have focus" mode.
I've always used the "Track must be selected mode" successfully, I just tried the "FX must have focus" mode to see if I found more comfortable to click on plugin windows rather than on tracks, but it does not seem to get midi feedback this way.
Anybody has the same issue? Thanks.
ReaLearn installer extends your REAPER VST path automatically, it should just work (assuming it's a normal aka non-portable REAPER installation). Doesn't it? It puts it to "C:\Program Files\ReaLearn\VstPlugins". But really, better don't mess with the paths, I put it there for a reason (32-bit/64-bit conflicts etc.). However, if you have a portable REAPER you should use the portable ReaLearn ZIP file.
Ahh - thanks helgoboss - I see it now.
I don't remember why I copied the dll when I first installed it, but it's working fine "as designed"
Managed to play with it for about 30 mins today. Works well. Feels like the real deal. Master track doesn't like it, throws up an error and a blank plugin window, but given how well supported this plugin is, that won't be an issue for long - and regardless the recent update contains a significant set of improvements.
As a step towards a control surface using a non-control-surface midi controller - this is so deeply useful. As a set of controllers for managing, for example, the MCP and TCP faders and pans across mutiple tracks and in any order (unusual and SO useful) - all of which by reaper-design are not controllable by MIDI CC - this plugin addresses a gap in reaper that desperately needed filling.
Keywords for me are fader control, pan control, fader MIDI controller, pan MIDI controller, MCP MIDI controller, plugin controller, FX controller - all of which massively under-describe what this plugin does, but I hope this helps someone searching for these features.
If you were using Trackreacontrol - or your web search brought up trackreacontrol multiple times in the first couple of pages of your search engine - stay here instead kiddies. This is the playground you are looking for. :-)
Sorry, I have a little problem with "FX must have focus" mode.
I've always used the "Track must be selected mode" successfully, I just tried the "FX must have focus" mode to see if I found more comfortable to click on plugin windows rather than on tracks, but it does not seem to get midi feedback this way.
Anybody has the same issue? Thanks.
If "FX must have focus" is enabled, MIDI feedback will only be sent if your FX has focus. In the (rather unlikely?) case that you want to *control* your FX only if the FX has focus but *receive feedback* from your FX even it doesn't have focus, just duplicate the mapping, disable feedback for the first, disable control for the second and disable "FX must have focus" for the second.
EDIT: Ah, I see. Maybe you are referring to the fact that feedback is not sent in the moment when the FX is focused? I'll improve that. Right now there seems to be a bug in the REAPER API which causes ReaLearn not to get notified when changing focus from e.g. REAPER main window to FX window. It only gets notified when changing inbetween different FX windows. So there's only so much I can do.
EDIT 2: Well, thinking about it, it would be sufficient for most use cases to receive focus changes between FX only. I'll release 1.7.1 later today which sends feedback on FX focus change.
EDIT: Ah, I see. Maybe you are referring to the fact that feedback is not sent in the moment when the FX is focused? I'll improve that. Right now there seems to be a bug in the REAPER API which causes ReaLearn not to get notified when changing focus from e.g. REAPER main window to FX window. It only gets notified when changing inbetween different FX windows. So there's only so much I can do.
That's true, I didn't even noticed the bug before reading this. Hope they'll get it fixed. Right now it seems like I just have to first click on any other FX window, then click the floating FX window I need to control
I just made a modest donation to thank your for your work and patience. Thank you.
Hi, Benjamin. Thank you for your continued work on this plugin.
I'm still trying to understand the purpose of the <Selected> track option. It's not working the way I expect it would. I would say it's actually worse since the last update since it ignores reordering even while the track is selected.
Here's my goal. I want to use <Selected> to set up dedicated mixing controls on a MIDI Fighter Twister. The problem is if the plugin count on a track changes, the mappings change. I was hoping the mapping would be specific to the chosen plugin and if that plugin was not present on the selected track, the mapping would sit dormant until another track is selected. As it is now, the mapping will take over whatever plugin is in the same slot, which is very undesirable in my opinion.
Please see the pictures I've attached. The mapping was set up on track 2 controlling Freq1 in PrimeEQ. On track 3 a MIDI arp was added before the VSTi. Now the mapping controls an LFO in PG-8X. So basically in normal use, where plugins are added and removed, that knob is at the whim of whatever parameter happens to occupy the right slot. Chaos ensues.
Last edited by ErBird; 08-08-2018 at 03:06 PM.
Reason: Spelling
I'm still trying to understand the purpose of the <Selected> track option. It's not working the way I expect it would. I would say it's actually worse since the last update since it ignores reordering even while the track is selected.
Here's my goal. I want to use <Selected> to set up dedicated mixing controls on a MIDI Fighter Twister. The problem is if the plugin count on a track changes, the mappings change. I was hoping the mapping would be specific to the chosen plugin and if that plugin was not present on the selected track, the mapping would sit dormant until another track is selected. As it is now, the mapping will take over whatever plugin is in the same slot, which is very undesirable in my opinion.
Well, there are several ways one could want to control different FX, depending on which track is currently selected:
Way 1: Based on the FX's position in the chain
Way 2: Based on the FX's type
Way 3: Based on the FX's name in the chain
Way 1 has the benefit that you can control FX of different types. But you need to take great care that you always use the same FX positions.
Way 2 has the benefit that you don't need to care about FX positions. But you can't control FX of different types and if there's more than one instance of a type in a chain, only one of it can be controlled.
Way 3 has the benefit that you don't need to take care of FX positions and can control FX of different types. But you need to take care of naming.
The last update makes way 1 possible. Way 2 and 3 are not possible yet. Before the update we had a weird mix between **based on the FX's unique ID** (when the track was selected) and **based on the FX's position in the chain**. At first I had to fix that.
Way 2 and 3 is stuff for future updates. I think what you want is way 3.