Comments (13)
The enable port works like this. It will send a midi message when that is toggled. I suppose you are using this on the mod duo or duoX?
from infamousplugins.
Yes, and yes.
But a trigger button only need a single press. Which is really convenient. Adding that will not remove any other features.
from infamousplugins.
I understand. I want this behavior too, but I feel that this needs to be an option of the controller (the mod firmware). Adding another port for a momentary button for the same function is a workaround and I'd rather not do that. Expecting every plugin developer to implement this on every plugin seems counter-productive when the host could implement it once and support any toggled type port on any plugin and allow the users to be creative with it. I really appreciate the offer for a patch, but I've considered this quite a bit. Many of my plugins would benefit from this feature (power-cut, stuck, mindi, etc).
I understand the way to implement it using the trigger port, but my plugins are used on desktop DAWs as well and adding a port will make the interface more confusing for those users, just to work around a missing feature of the MOD. I've brought this up before, but I think we should maybe bring it up on the forums again and see if we can drum up enough interest for them to prioritize it.
Edit: I've talked to falktx a bit about it. He says this is on the roadmap but is lower priority than the new product they're trying to get ready. I don't know the timeline, but I think it still would be great to get this feature brought up again.
from infamousplugins.
I see. But I don't think it is a good idea to mix concepts. Or maybe i do not have the full picture.
Cause a trigger is not a toggle. The behavior is not the same, nor the look and feel, nor the feedback, nor the API. This decision have to be taken by the plugin. Providing more binding feature in the host is nice for advanced people (to deal with dirty things), but will add more confusion for sure. Cause most of toggled ports was not designed to be triggered. Cause enabling a plugin do not mean sending a signal.
from infamousplugins.
Yes, your argument is strong in the case of the mindi, as it is actually an event you are creating. On the other plugins I mentioned it really is a momentary toggle I want. I can't think of an example of a toggled control that would be bad to map to a momentary button (some might be less useful or more CPU intense but I like having the option). I'm interested in examples of such.
But that's not really here nor there. For mindi probably the best way to proceed is what you propose, adding an additional port, but I think to really make this lv2:trigger port useful for anything beside just sending notes, we should add a 2nd DATA2 parameter that is optionally sent when the trigger button is released. This is basically what the auto-note-off is doing, but allows for CC's or PC messages to have similar behavior but configurable. With that, we'd want the trigger button to have another port to allow it to have toggle or momentary behavior (default momentary). Does this make sense? This can turn the Mod footswitches into a fairly configurable midi controller.
I really appreciate the discussion.
from infamousplugins.
a 2nd DATA2 parameter that is optionally sent when the trigger button is released
I see. You expect to have information on the duration the user press the button.
It makes sense, i guess especially for music. But if i am right it is not part of the LV2 specs (trigger
is specified as one shot, toggled
is not supposed to be auto-released). Sure the host could deal on it's own with a momentary toggle
, but it would be better to put it in the specs. Cause it makes the result easier to bind. I don't know how they deal with proposals.
And in your case i guess you also expect your port to be connected to both toggle buttons, or momentary toggle buttons. And this should also be described (both widget are allowed). I don't know if this choice could always be proposed to a user or if it's a designer decision. Extra host features, LV2 specification, or 2 different ports for basically the same thing.
Anyway, i just wanted to say that it is probably not in the Mod side to deal with. Or it is like designing a LV2 plugin only for them. Except the momentary
concept already exists.
from infamousplugins.
I see. You expect to have information on the duration the user press the button.
Well, with the trigger port, you will know exactly how many cycles the user is holding the button for. Typically this resolution is sufficient, at least on the mod it will be fine.
the host could deal on it's own with a momentary toggle, but it would be better to put it in the specs
I'm not sure if you are proposing a hint that it can be a momentary or a designator that it should be a momentary. I believe that the user should have the option to select the behavior based on what they want on their pedalboard. Specifically I know of hardware pedals like the EHX Freeze (which was my inspiration for the infamous stuck) and the Digitech Freqout that have selectable bypass switch behavior momentary or toggle. I would like this behavior in the MOD.
I don't know how they deal with proposals.
They accept proposals after discussion and convincing them that the extension is necessary. Right now I'm honestly not convinced that it needs to be in the plugin meta data. For a DAW it's not very useful as its easy to click a mouse twice, its just the MOD buttons that need the selectable behavior. Do you agree with that?
I don't know if this choice could always be proposed to a user or if it's a designer decision.
I don't think this option needs to be restricted to specific toggle ports determined by the developer, because to my mind it has less to to with the plugin and instead has to do with the controller hardware. This is re-enforced to me by the fact that most midi controllers offer this option for buttons. The feature certainly will be more useful on some ports than others, but I like the idea of allowing some user creativity with the option.
Or it is like designing a LV2 plugin only for them.
The infamous mindi to my knowledge has not been used anywhere else. It was designed for the mod and isn't very practical in any other context I know of. This is why I don't mind adding a workaround type solution for it. However more broadly, thinking of my other effects, I'd like this option for the hardware control on many toggle parameters.
If you'd like we can move this discussion the the LV2 mailing list and see if there is some consensus there on whether this is something that should be added to the spec.
from infamousplugins.
Well, with the trigger port, you will know exactly how many cycles the user is holding the button...
According to the spec i think you could receive a sequence of 1 0 1 0 1. I did not check, but it could be host dependent.
Do you agree with that?
Not really. Cause of the user side. The affordance of the widgets are not the same. And if you can bind it, it requirements extra knowledge, which can be obvious or not. But it's fine, i can live with it.
If you'd like we can move this discussion the the LV2 mailing list and see if there is some consensus there on whether this is something that should be added to the spec.
I honestly do not have the motivation for :-) I also guess, as you said, that most of people design LV2 plugins for a specific host. Binding generic widgets is not an easy task, and is maybe not targeted by LV2, then that's maybe not a good idea to create a huge spec for nobody.
from infamousplugins.
i think you could receive a sequence of 1 0 1 0 1. I did not check, but it could be host dependent.
The host is supposed to set the port value back to 0 each cycle, but if the user is still holding the button then it would be 1 again each time run() is called. 1 1 1 1 1 is holding the button, 1 0 1 0 1 would be 3 separate presses. This is the only way the 1 button loopers are working on MOD.
most of people design LV2 plugins for a specific host
I didn't mean that. Mindi is a bit of an exception, but the point of a plugin standard is to allow useage in many hosts. It is fair to say though that most devs are usually testing more in certain hosts. Especially for free software like mine.
I think we agree to disagree on some of these points but most of them don't really matter as MOD won't get to changing anything anyway. If you'd like to put in the work to add the trigger port, I'd be willing to merge a pull request (though I'll probably add in the additional features I've mentioned as well before a full release). That way at the least you can build a custom version of Mindi that you can use personally
from infamousplugins.
if you want to look at the mindi2 branch it now has the momentary port. I'll try to build it for mod soon to test, but on desktop it seems to work as expected. I'll merge this after I add a few presets to illustrate good useage of the new features.
from infamousplugins.
Thanks a lot. It should simplify a lot my rooting :-)
from infamousplugins.
this is merged to master and there are some mod builds you can use in #46
from infamousplugins.
Nice, thanks a lot.
from infamousplugins.
Related Issues (20)
- lushlife in ardour, X values not retained on gui reload HOT 1
- i tried to compile the infamousPlugins but get an error HOT 5
- lushlife and envelopper follower (CV) not working HOT 11
- infamous stuck window isn't well suited HOT 3
- Cannot run lushlife HOT 6
- windows and mac HOT 2
- CASynth Midi Panic (and hanging notes)
- The last commits seems to break the Zynthian build HOT 9
- Compilation error with new lv2 release (1.18.0)
- [Mindi] Pitch wheel/bend messages (msgtype 14) incorrectly converted into SYSEX messages (msgtype 15) HOT 4
- [Mindi] Channel pressure/aftertouch (msgtype 13) should really use DATA2 ("Value") for value, not DATA1 ("Note/CC/PG Number") HOT 4
- Infamous Plug-ins fail to load in Ardour 6.5 HOT 4
- Please clarify in README where the ntk dependency should be sourced from HOT 5
- What version of lv2 is required ? HOT 2
- Fail to buld with lv2 1.18.0 HOT 1
- location of (f)ltk package HOT 5
- Please do a release HOT 1
- Stuck pedal plugin making distorded noise when playing chords HOT 1
- Installation Troubles - /usr/bin/ld: cannot find -lzita-resampler: No such file or directory HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from infamousplugins.