Yahoo Groups archive
Thread
2011-05-17 by bitman2112
I am working on a control surface plugin. I have a desperate situation where I need to determine whether the change to a DAW widget came from spinning the widget in he DAW or if it was changed by spinning the encoder on the BCR. How do I peek in at an encoder's current value setting using BCL, C, or otherwise. Thanks in advance.
2011-05-17 by Martin Klang
ah! that old chestnut. Having done a few GUI / midi apps myself it is a conundrum I recognise well. Requesting the value from the device will never be a robust solution, and you're multiplying MIDI traffic x3 quite unnecessarily. If you consider that turning a couple of high-resolution knobs at the same time generates a veritable shitload of messages already, then you'll realise there must be a better solution. I would suggest that you look into adding state keeping to your widgets to solve the problem, so that you always know where an update came from, and hence where it needs to be sent on to. All you should have to do is to split the update interface into two, one for the GUI/DAW, one for MIDI, and keep track of where the update call came from. There's also a more generalised approach which involves registering callbacks. This might be necessary if there's a possible 3 or 4 sources of updates, e.g. loading a preset, or other actions originating from within your application. Look out for feedback loops too. Some GUI widgets will unconditionally re-send an update to its listeners when you update its value, though with most toolkits you can control whether it does or not. What programming language / platform are you on? I have some Java and C++ / Juce code [1][2] which you are welcome to peruse. hth, /m [1] http://mars.pingdynasty.com/software.oml [2] http://git.pingdynasty.com/?p=miditoys.git;a=summary
On 17 May 2011, at 17:28, bitman2112 wrote: > I am working on a control surface plugin. > > I have a desperate situation where I need to determine whether the change to a DAW widget came from spinning the widget in he DAW or if it was changed by spinning the encoder on the BCR. > > How do I peek in at an encoder's current value setting using BCL, C, or > otherwise. > > Thanks in advance. >
2011-05-17 by sghookings@tiscali.co.uk
If your GUIs are in Java, then congrats ... they are superb GUIs. I didnt persue Java for MiniakTools because I had poor experience with old Swing etc. But your GUI is just great. Regards Steve H --- In bc2000@yahoogroups.com, Martin Klang <mars@...> wrote:
> > > ah! that old chestnut. > Having done a few GUI / midi apps myself it is a conundrum I recognise well. > > Requesting the value from the device will never be a robust solution, and you're multiplying MIDI traffic x3 quite unnecessarily. If you consider that turning a couple of high-resolution knobs at the same time generates a veritable shitload of messages already, then you'll realise there must be a better solution. > > I would suggest that you look into adding state keeping to your widgets to solve the problem, so that you always know where an update came from, and hence where it needs to be sent on to. > All you should have to do is to split the update interface into two, one for the GUI/DAW, one for MIDI, and keep track of where the update call came from. > > There's also a more generalised approach which involves registering callbacks. This might be necessary if there's a possible 3 or 4 sources of updates, e.g. loading a preset, or other actions originating from within your application. > > Look out for feedback loops too. Some GUI widgets will unconditionally re-send an update to its listeners when you update its value, though with most toolkits you can control whether it does or not. > > What programming language / platform are you on? > I have some Java and C++ / Juce code [1][2] which you are welcome to peruse. > > hth, > > /m > > [1] http://mars.pingdynasty.com/software.oml > [2] http://git.pingdynasty.com/?p=miditoys.git;a=summary > > > On 17 May 2011, at 17:28, bitman2112 wrote: > > > I am working on a control surface plugin. > > > > I have a desperate situation where I need to determine whether the change to a DAW widget came from spinning the widget in he DAW or if it was changed by spinning the encoder on the BCR. > > > > How do I peek in at an encoder's current value setting using BCL, C, or > > otherwise. > > > > Thanks in advance. > > >
2011-05-18 by Ron Anderson
I have a state matrix that holds the values. I did consider doing what you have said, keeping a log of where the last update came from in the state matrix but thought if I could just read the value......
Now that you have seconded the motion to record the last update source, I'll do it.
Thank you for your reply.
--- On Tue, 5/17/11, sghookings@... <sghookings@...> wrote:
From: sghookings@... <sghookings@tiscali.co.uk>
Subject: [bc2000] Re: Reading BCR current encoder value in .bcl, c or hex please?
To: bc2000@yahoogroups.com
Date: Tuesday, May 17, 2011, 7:13 PM
If your GUIs are in Java, then congrats ... they are superb GUIs.
I didnt persue Java for MiniakTools because I had poor experience with old Swing etc. But your GUI is just great.
Regards
Steve H
--- In bc2000@yahoogroups.com, Martin Klang <mars@...> wrote:> > > ah! that old chestnut. > Having done a few GUI / midi apps myself it is a conundrum I recognise well. > > Requesting the value from the device will never be a robust solution, and you're multiplying MIDI traffic x3 quite unnecessarily. If you consider that turning a couple of high-resolution knobs at the same time generates a veritable shitload of messages already, then you'll realise there must be a better solution. > > I would suggest that you look into adding state keeping to your widgets to solve the problem, so that you always know where an update came from, and hence where it needs to be sent on to. > All you should have to do is to split the update interface into two, one for the GUI/DAW, one for MIDI, and keep track of where the update call came from. > > There's also a more generalised approach which involves registering callbacks. This might be necessary if there's a possible 3 or 4 sources of updates, e.g. loading a preset, or other actions originating from within your application. > > Look out for feedback loops too. Some GUI widgets will unconditionally re-send an update to its listeners when you update its value, though with most toolkits you can control whether it does or not. > > What programming language / platform are you on? > I have some Java and C++ / Juce code [1][2] which you are welcome to peruse. > > hth, > > /m > > [1] http://mars.pingdynasty.com/software.oml > [2] http://git.pingdynasty.com/?p=miditoys.git;a=summary > > > On 17 May 2011, at 17:28, bitman2112 wrote: > > > I am working on a control surface plugin. > > > > I have a desperate situation where I need to determine whether the change to a DAW widget came from spinning the widget in he DAW or if it was changed by spinning the encoder on the BCR. > > > > How do I peek in at an encoder's current value setting using BCL, C, or > > otherwise. > > > > Thanks in advance. > > >
2011-05-18 by Martin Klang
hey, thanks! If you need really tight MIDI timing then Java is not really up to scratch. Also Java MIDI on Mac has had a history of problems, really boring stuff and huge time waster for anyone developing to that platform. I've otherwise used the Juce [1] library with C++ which is really quite good - let's you do easy, cross platform gui, midi and sound. I see the Java apps as prototypes really - quick turn over time from idea to working code. /m [1] http://www.rawmaterialsoftware.com/juce.php
On 17 May 2011, at 20:13, sghookings@... wrote: > If your GUIs are in Java, then congrats ... they are superb GUIs. > I didnt persue Java for MiniakTools because I had poor experience with old Swing etc. But your GUI is just great. > > Regards > > Steve H
2011-05-18 by Martin Klang
Shouldn't be a problem to stick with the state matrix, just as long as the updates are handled correctly. You might want to have a look at something like Multiple Dispatch [1] or Visitor [2] patterns, for ideas. good luck, /m [1] http://en.wikipedia.org/wiki/Multiple_dispatch [2] http://en.wikipedia.org/wiki/Visitor_pattern
On 18 May 2011, at 02:15, Ron Anderson wrote: > > > I have a state matrix that holds the values. I did consider doing what you have said, keeping a log of where the last update came from in the state matrix but thought if I could just read the value...... > > Now that you have seconded the motion to record the last update source, I'll do it. > > Thank you for your reply. > >
2011-05-18 by Martin Klang
what did you use for MiniakTools? I like the colours! Couldn't find the source on sf, though - not using svn? /m
On 17 May 2011, at 20:13, sghookings@... wrote: > If your GUIs are in Java, then congrats ... they are superb GUIs. > I didnt persue Java for MiniakTools because I had poor experience with old Swing etc. But your GUI is just great. > > Regards > > Steve H
2011-05-22 by sghookings@tiscali.co.uk
Hi Sorry for late reply, was on business in Vienna. I used C# simply because our mobile developers use it (we use C++ in db code). They suggested it was easier to design GUIs than Java. This is all relative; a good design tool could make Java easy to use. Because I am still not understanding C# I havent put the code up, but soon I will. I finally worked out (I think) why I was sig11 in obscure places. The intention was always to find a hardware solution, and the BCR was the closest I could find. I am grateful to all those who found out about it's internal language. The ability to use buttons to control low cardinality NRPNs is cool. Just need to find a kinky solution for incr CC06/38 to see if one can make the -ve (by large +ve increment). Regards Steve H More details of the issues I found with C# and midi. I had to learn then write the interop code to call winmm.dll function from with C#. Then I had to find our about delegates (function pointer :-)). Next, to "invoke" methods from the GUI thread (yes I did try to update GUI objects outside the GUI thread ... not anymore!). Finally, because you marshall code from the managed (C#) world to the unmanaged (dll) - when you pass a managed object as a handle to the unmanaged dll, from the pushing of info onto the method's parameter stack until it's popped, the object is in use. After this, C# says "oh you not using me ... I will reclaim you". Alas, the callback IS still holding a reference ... c# doesnt know. I think the solution to this last one is to make a list, in a constructor, which hopefully add a keep count (and hence stops the GC from tearing the objects down). Hopefully this will work else I gotta go back to C++ where a "new" remains until you delete, or the program crashes :-). --- In bc2000@yahoogroups.com, Martin Klang <mars@...> wrote:
> > > what did you use for MiniakTools? > I like the colours! Couldn't find the source on sf, though - not using svn? > > /m > > On 17 May 2011, at 20:13, sghookings@... wrote: > > > If your GUIs are in Java, then congrats ... they are superb GUIs. > > I didnt persue Java for MiniakTools because I had poor experience with old Swing etc. But your GUI is just great. > > > > Regards > > > > Steve H >