MidiFilter template project

[data]

@kraken

my idea is to have the Atom class as you, but instead of holding internally a value, it just “points” to a real variable defined elsewhere: this way i can have proxies over that float/double/int/… value defined as member of your synth, obviously for saving a lot of function calls in processing blocks (which also kills your plugin in debug mode) and using your values directly.

This is the approach I took.

[quote=“kraken”]i found very useful the idea of having a parameter split in Policies (if i’ve understood correctly your idea) cause for me a parameter is some value that i use in dsp code, and usually doesn’t mean to be equal to the value the frontend would like to display, and could be different to the value the host will give me.
so in a tipical environment i’ll have to deal with 3 “languages”: normalised language (0…1) spoken with the host, denormalised language (-2pi…2pi) tipically used inside dsp code, and display language (“0.000 %”) used in UI.[/quote]

I think this concept of “languages” is a very good way to think about the problem.

The concept seem obvious, but I have also found it useful to think of a native parameter (there’s probably a better word, but …) – this is the actual parameter itself, and there should only be one of these. All the other representations are translations of it and must follow it, even if copies are also kept somewhere else, as they are in the host and in UI controls.

So the basic task of a parameter system is to keep the copies of the native parameter in sync with the native parameter.

For most situations the native parameter would probably be the one used by DSP code – but not necessarily. But there should definitely be a native parameter somewhere.

In my classes, the native parameter is always the one pointed to by the subclasses. I don’t allow the native parameter to be stored in the parameter classes; these classes are only for manipulating the native parameter.

[data]

I like functors, but I don’t understand their value here – but I may be missing something (not at all unlikely)

As I understand things, the advantages of functors are:

• They can be inlined (but for this to happen, the caller must have a template parameter for the functor type)

• They are excellent for dynamic binding (as in mdsp’s code)

• They have an intuitive syntax to use

Disadvantages:

• They can be complex to set up – they often require a good deal of machinery to make them work

• For inlining to work, the caller must have a template parameter

• Without inlining, they can actually be slower than virtual functions, because of extra indirection

• They can expose only one operation (in mdsp’s code this is the set operation)

With virtual functions, you don’t (usually) get inlining, but there isn’t as much machinery to set up, and you can do multiple operations.

Also, for this application, is dynamic binding really needed? I would tend to set up a parameter structure once, and not change it after that.

[kunitoki]

this mix of functors and signals/slots lets you bind a single logic parameter object to a “slot” which is signalled of any changes with a call to a set method you can have defined arbitrally before. so it will not limit which signal methods you have (especially if you already got your dsp classes up and running)…

i think this approach is good cause is less intrusive, more intuitive and easy to use (of course have a clean signal-slot/functor implementation is hard to setup unless u use already Qt, libsigc++, Sigslot or boost… what about having a clean simple signal slot in juce ?).

the only thing that makes me think twice about it, if you take internal parameter modulations into account, then your setter method haven’t got any use here, as u would calculate your parameter real values before the inner loop and not directly when signalled, and functors will lead to a general loss of control over your real values, but maybe i’m wrong…

[mdsp]

in the case of modulations, I mix both approaches.

the setter only assign a variable but the dsp parameter update is postponed to the beginning of the next audio block.

[data]

[quote=“kraken”]this mix of functors and signals/slots lets you bind a single logic parameter object to a “slot” which is signalled of any changes with a call to a set method you can have defined arbitrally before. so it will not limit which signal methods you have (especially if you already got your dsp classes up and running)…

i think this approach is good cause is less intrusive, more intuitive and easy to use (of course have a clean signal-slot/functor implementation is hard to setup unless u use already Qt, libsigc++, Sigslot or boost… what about having a clean simple signal slot in juce ?).[/quote]

Ah … well, if it’s signals & slots we’re after, that’s a different matter. I didn’t pick up on that.

I think JUCE could have used signals+slots (of course Jules should have the final word on this) – it seems to be one of the basic choices for any toolkit architecture – but instead JUCE uses trees of specialized broadcaster / listener classes, like ChangeBroadcaster, SliderListener etc. In some other toolkits (e.g., Qt) this is all done by the same signal + slot mechanism.

JUCE’s approach seemed limited to me at first, but I haven’t found that it is actually very limiting in practice – and it’s simple and fast, which is good. I think it works very well for the audio / control-panel kinds of apps it’s intended for.

Anyway, isn’t a class tree with listener lists etc. equivalent to a signals+slots implementation? It tends to be more intrusive to the code, but I think it doesn’t have to be. You can easily make a subclass that accepts member function pointers, for instance. Actually you can make subclasses which use functors etc. if you want that.

For my stuff, I’m still not convinced that a general-purpose signals + slots design is worth it; it looks like a lot of typing and can become a nightmarish thicket of templates (see libsigc++!). But I’m not working on anything supremely complex – actually I’m not doing DSP at all in my current plugins. (But I still need to delay updates and get parameters quickly, so it’s not so much different.)

@kraken

the only thing that makes me think twice about it, if you take internal parameter modulations into account, then your setter method haven’t got any use here, as u would calculate your parameter real values before the inner loop and not directly when signalled, and functors will lead to a general loss of control over your real values, but maybe i’m wrong…

The setter might be in another class which delays updates until the beginning of the next block, or this might be done inside the DSP class – so yes, it’s disconnected from the system, but would be anyway I think.

[kunitoki]

@data

JUCE’s approach seemed limited to me at first, but I haven’t found that it is actually very limiting in practice – and it’s simple and fast, which is good. I think it works very well for the audio / control-panel kinds of apps it’s intended for.

yeah, the broadcast/listen will suit 99% of the needs in a typical audio/gui application, and i don’t think this is limiting (actually, but i have to admit the first time i saw juce i was thinking the same as you)

@data

Anyway, isn’t a class tree with listener lists etc. equivalent to a signals+slots implementation? It tends to be more intrusive to the code, but I think it doesn’t have to be. You can easily make a subclass that accepts member function pointers, for instance. Actually you can make subclasses which use functors etc. if you want that.

i’ve started thinking a way to make a templatized listener class with functors that easily can be less intrusive over the classes you already have and coded without thinking of listening / broadcasting purpose… and this especially talking about plugin gui controls listening of Parameters changes, gui controls broadcasting changes to parameters and dsp classes listening of Parameters changes. this would’t be so difficult to setup, but i thin extremely useful when used with care.

@data

For my stuff, I’m still not convinced that a general-purpose signals + slots design is worth it; it looks like a lot of typing and can become a nightmarish thicket of templates (see libsigc++!). But I’m not working on anything supremely complex – actually I’m not doing DSP at all in my current plugins. (But I still need to delay updates and get parameters quickly, so it’s not so much different.)

me too, what i think now is, trying to lead the broadcast/listener paradigm to a more dynamic and less intrusive way to link classes togheter is a better way to go.

[mdsp]

[quote=“data”][quote=“kraken”]
JUCE’s approach seemed limited to me at first, but I haven’t found that it is actually very limiting in practice – and it’s simple and fast, which is good. I think it works very well for the audio / control-panel kinds of apps it’s intended for.
[/quote][/quote]

I agree, but say you have 1000 parameters (I can give you a list of plugins which have more than that!)

would you poll for each in changeListenerCallback()? (without talking about having to do that manually instead of having a manager doing the hard work for you)
while at the same time you know that you call sendChangeMessage() each audio block to inform about timePosition update.

a reasonable alternative to me would be to call a method like
sendParameterChangeMessage(paramId); which would use the Message dispatcher to tell the UI that it needs to poll for that specific parameterId

another approach I might use would be to send messages using a client-server protocol like Open Sound Control for example. It might still use Juce Messages as the transport or it could be UDP sockets…

Maybe I’m missing the obvious, and I’d be happy to hear about all the different that you use.

However as I’ve said previously, it seems that Components are not supposed to override the handleMessage() method, and there’s no alternative to add you own.

//============================================================================== void Component::handleMessage (const Message& message) { if (message.intParameter1 == exitModalStateMessage) { exitModalState (message.intParameter2); } else if (message.intParameter1 == customCommandMessage) { handleCommandMessage (message.intParameter2); } }

Juce’s Commands or Action are close to what I’m after, I just need more than int or String

Jule, what’s the JUCE way to add your own custom Messages? there are stuff like that in the MessageManager which make me think that I’m not supposed to implement an OSCMessageBroadcaster for example.

friend class ChangeBroadcaster;
friend class ActionBroadcaster;

I’m sure I could find ways to make it work by my own, but I’d prefer to do it the JUCE way, i.e. simple, elegant and fast!

[jules]

You can always roll your own MessageListener and send it objects that are a subclass of Message. Don’t use a componenty to receive them though, you’ll need to have your own class to do that.

[mdsp]

I’ll try to explain what I’ve understand about sending your own CustomMessages, tell me if I’m wrong.

to send async Messages I need to be a MessageListener.

then somewhere my code will call MessageListener::postMessage(new CustomMessage(...));
and later on, the MessageManager will call me back triggering MessageListener::handleMessage(const Message& message);. If I’ve understand correctly, this is where I can notify all the CustomMessage Listeners using direct function calls.

I realize that in fact the CustomMessageListeners don’t have to be MessageListeners themselves. They should rather implement a callback of my choice like void customMessageCallback(...); for example.

am I right?

[jules]

yes, that sounds about right.

[ambrosea]

there seems a lot of talk on parameter handling in this thread, but for me the main point has been lost - writing midi filters. the template that haydxn mentioned is no longer available and I’m still struggling to write a midi only filter in JUCE - I was able to write on via the raw VSTSDK, but doing the GUI for was a pain, and the current plugin mechanism seems to be more geared towards audio effects and synths. Can anybody give me any tips on write a filter that modifies midi mesaages?

thanks.

ambrosea

[ambrosea]

just to say I worked out what I was doing wrong in my Juce Midi-Only plugin. Got it working now.

[kapser]

Where can I find a miditemplate or can somebody send me some midi example code ? Need someting to start with.

The link in this forum doesn’t work anymore.

Thank you in advance.

[peteatjuce]

I second that request - has anybody got any example code?

[peteatjuce]

Has anybody seen this file anywhere…?

http://haydxn.net/content/code/MidiFilterTemplate/MidiTemplate.zip

I ask as I need to get a Midi Filter project running … pronto! … … with Juce.

If anybody out there has done this, or wants in some way to share effort in getting things in this area all up and running, then please let me know!

Pete

[jules]

I doubt if that example would still be up-to-date with the latest audio plugin framework even if you find it, so might not be worth your time to look for it.

Making a midi filter is a no-brainer though - it’s just a normal filter, where you ignore the audio stream. And there are a couple of flags you need to set in the plugin characteristics file. That’s it.

[ShareCommunity]

Possibly slightly OT / I’m fairly new at C++ and the way things should be done, but…

In a previous posting( when I embarrassed myself by proclaiming my utter ignorance of the VST SDK) I mentioned how TobyBear did something like this (albeit in Delphi) - There was a structure where the user specifies the parameter name, and features (param name, range, mapping to float / exponential scaling etc) which worked remarkably well - There were 2 variants of get/setParam - One which did nothing (just handled floats in the range 0.0 - 1.0) the other mapped to a range of given values/scaling methods (e.g. linear / exponential / other / string?!)

[jules]

Sure, that sort of thing would be good to have in there…

[kunitoki]

i’ve got a pretty scalable and configurable parameter system based on fast delegates, the classes come up after a discussion with other people here.
the good thing, is that you declare parameters and how they will appear in the hosts, but then attach the getter and setter methods to one of your own dsp classes get/set function directly.
it’s pretty cute to use and leave the whole plugin well organized and let you use member variables directly instead of having a lot of “filter->getParameterScaledByIndex (MY_PARAM_INDEX)” in process blocks…

you can find some classes inside the “jucetice” directory in the
jost sources (if it is online cause i’m having problems getting it)

there isn’t an usable example inside it, but i will provide you an example… if you need it.

[peteatjuce]

Hi Jules,

Making a midi filter is a no-brainer though - it’s just a normal filter, where you ignore the audio stream. And there are a couple of flags you need to set in the plugin characteristics file. That’s it.
<<<

Yep, I get that bit.

The reason for my asking this is that I’ve found that various DAW programs all handle MIDI event generation from VST plugins inconsistently (e.g. Cubase SE doesn’t allow passing of MIDI events generated from a VST into a separate VST; similarly for Sonar HS 4).

So, what I’m stuck with, is how I could implement the UI for a “MIDI Filter” using Juce. Specifically, using the “Steinberg MIDI Effect API” (i.e. built as a pure MIDI effect, not as a VSTi).

I like the look of Juce GUIs and would like to find a way to use it to create this sort of plugin…

HTH

Pete