The Horrors of GUI-programming for beginners [introducing: Lickety Strip Control]

[Tallisman]

this thread was once called introducing: Lickety Strip Control [formally Bin Control]

here is the concept and perhaps it can be implemented
thanks to the new APIs and geeky stuff that Justin and
co have opened up to the wonderful world of developers
and coders much more intelligent than I:

Lickety-Strip Control formally Bin Control

• A dock-able window (the width of the mixer when
  showing the master +1 track) that responds to track
  selection (click on track one, it displays the Track
  one Configuration).
• Contains a pulldown menu that grants access to any
  VST in the selected track's FX Chain.
• Similar to the virtual Keyboard, in that it sends
  midi CC messages to the plugins in the FX chain.
• Has 3 modes: 1. Auto: which automatically maps
  the first 45 parameters of the selected VST. 2. User:
  allows the user to map selected parameters from the selected
  VST. 3. Multi-User: Allows the user to map any 45
  parameters from any plugin in the selected track's FX bin.

here's a crappy sketch:

click for larger view


TheMulti-User Mode
Selecting Multi-User Moded from the Lickety-Strip control target pulldown
menu opens the FX chain fro that track. The user can then select
a plugin in the FX bin, click midi learn and touch a slot in the
Lickety-Strip Control window. That Parameter is then mapped to that slot.
Ideally it would be killer to drag a Lickety-Strip Control slot to a
parameter (like dragging sends) and create the link as such.

It would be great, and probably less work, if we could could just
reuse the Reaper send Elements so that there would be no need to
have more GUI elements and integration would be tight with any
given theme.

Lickety-Strip Control Configurations should be save-able and recallable.
They should be stored with track presets and project templates.

I will add more Ideas as they come. Please feel free to do the
same, or better yet,

get busy coding

many greetings

.t

edit: and thus we have solved the per-track eq problem:
add the eq of choice to the default track config. add a Lickety-Strip Control to the mix, map to taste and save with the default track.

[Tallisman]

Here is a little crappy mock-up showing the control pannel and a bank of assigned and unassigned parameter slots.


it re-uses current Reaper grafix. which allows for 45 parameters to be assigned and controlled from the space where the navigator is in this image:

image: https://stash.reaper.fm/oldsb/9558/10...My-Desktop.png
(image removed to make this thread easier to read)


.t

[Lawrence]

get busy coding

I'm sure X will have that working by this weekend.

P.S. It's weird to see a scanned hand drawn sketch posted. I bet that took a little time to sketch out.

[Xenakios]

Originally Posted by Lawrence

I'm sure X will have that working by this weekend.

P.S. It's weird to see a scanned hand drawn sketch posted. I bet that took a little time to sketch out.

Glah, just look at my grim response to your VB DLL thread :

http://www.cockos.com/forum/showpost...2&postcount=26

[Lawrence]

Ah... stick with it.

If Deric or someone (hint, hint) would start a "C for Dummies 101" thread here I might be tempted to give it a shot. It looks so hard (and knowing me) it would have to stay interesting.

[Xenakios]

Originally Posted by Lawrence

Ah... stick with it.

If Deric or someone (hint, hint) would start a "C for Dummies 101" thread here I might be tempted to give it a shot. It looks so hard (and knowing me) it would have to stay interesting.

Again, I must iterate : C/C++ is not incredibly hard for someone coming from Pascal/Delphi or even Visual Basic. (I would not call easy, either.) It is the win32 programming that is the problem, unless you find a way to get around the low-level complexities of that. Visual Basic and Delphi hide all the complexities involved in Windows programming about the GUI stuff. And without a GUI most stuff isn't so great. And a GUI, any kind of GUI, is unbelievably hard to program in the low-level win32 way. There is no comparison to VB or Delphi. You have to experience it for yourself to understand the Hell of it all.

Look at this relatively innocent dialog box :



Can you guess how long it took for me to make the win32 API code that makes this appear on the screen, handle the user input (basically what happens when the buttons are pressed) and place the edit cursor into the text box when the dialog appears on the screen? (You can't see the caret in the screenshot, but it's there when it's running.) I would have put this together in Delphi (or in Visual Basic, although I've used that last time maybe in 1998) in under 5 minutes. Now it took a long time. Granted, I am a beginner to all this stuff and it might get easier with time, but aaaargh, it was ridiculous! The little fiddling with C++ to make this thing do what it should with the Reaper APIs will take very little time and effort in comparison to the dialog box code. It's so depressing. I want that Reaper API DLL that is callable from other languages now, too...

[Lawrence]

Originally Posted by Xenakios

Look at this relatively innocent dialog box :



Can you guess how long it took for me to make the win32 API code that makes this appear on the screen, handle the user input (basically what happens when the buttons are pressed) and place the edit cursor into the text box when the dialog appears on the screen? (You can't see the caret in the screenshot, but it's there when it's running.)

Dude, I have no concept of how that's done. Can you show us the source code that makes that happen? You're scaring me.

And reinforcing my belief that I should probably avoid it as it's way over my head.

I can only assume that you have to go get (and configure the basic properties of) each one of those Win32 classes and objects manually in code. Button class, window class, edit class etc.

Ouch! Source code samples please so I can at least have a sniff of a clue... I'm clueless.

[earlabs]

Originally Posted by Xenakios

Look at this relatively innocent dialog box :

That's no innocent dialog box! That's exactly what I asked for!

[Xenakios]

To open the dialog box (that has been designed with other methods, not nearly as nice as the form designers in VB and Delphi) :

DialogBox(g_hInst, MAKEINTRESOURCE(IDD_RENAMETAKEDLG), g_parent, TakeRenameDlgProc);

To make the dialog box do the GUI interaction stuff, I need that TakeRenameDlgProc-function :

BOOL WINAPI TakeRenameDlgProc(HWND hwnd, UINT Message, WPARAM wParam, LPARAM lParam)
{
	//
	switch(Message)
    {
        case WM_INITDIALOG:
			SendMessage(hwnd, WM_NEXTDLGCTL, (WPARAM)GetDlgItem(hwnd, IDC_EDIT1), TRUE);

			//SetFocus(GetDlgItem(hwnd, IDC_EDIT1));
        return TRUE;
        case WM_COMMAND:
            switch(LOWORD(wParam))
            {
                case ID_TAKEONLY:
                    MessageBox(hwnd, "Renaming Take Only","Info",MB_OK);
					// DO...() the stuff
					EndDialog(hwnd, IDOK);

                break;
                case IDC_CANCEL:
                    EndDialog(hwnd, IDCANCEL);
                break;
            }
        break;
        default:
            return FALSE;
    }
    return TRUE;

}

It may look insane to anyone familiar with VB and Delphi, and let me tell you, it IS! Also that doesn't yet handle the cases of : the user pressing the red X-button to close the dialog and it does not do anything yet with the second button for renaming both the take and the disk file...(Those are quite trivial to add there, but it sure doesn't make the code look any prettier.)

[Lawrence]

Ouch!

Originally Posted by Xenakios

You have to experience it for yourself to understand the Hell of it all.

I heard someone say that about crack once... ... and also marriage.


P.S. What is the Switch() function doing? Or is that a procedure? Never mind, I see... it traps the user input for the buttons... I think.

GAWD!

It may look insane to anyone familiar with VB ...

Talk about an understatement. Funny thing is, the code lines that seems to trap / parse the user action on the buttons looks much shorter than what it would be in VB, but yeah, if it takes 6 hours to get there well... that's another thing.

This -> MessageBox(hwnd, "Renaming Take Only","Info",MB_OK); is almost identical

..to what it would be in VB...

response = msgbox("Renaming Take Only", "Info", vbokonly [+ vbinformation or question or whatever])

[Xenakios]

Originally Posted by Lawrence

Ouch!



I heard someone say that about crack once...


P.S. What is the Switch() function doing?

Switching between "cases"? Basically, what happens there is that Windows calls that function (procedure) TakeRenameDlgProc (that must return a boolean result) with different messages like WM_INITDIALOG and WM_COMMAND and then in the switch case-mess I have to react to them in different ways. It sure isn't as neat as the automatically generated "event-handler code" thing in Delphi and VB...

[sws]

OK, this is probably bad timing, but Xen, did you look at the code in jmde\reaper_ninjamloop\main.cpp? Justin gives you a nice example of how to do much of what you just said took you forever.

Not to oversimplify here, but you create the dialog resource (much like VB) in the resource editor, you make it appear with DialogBox(handle_to_you, MAKEINTRESOURCE(IDD_YOURDIALOG),handle_to_reaper,d ialogBoxFunction), then all the magic happens in dialogBoxFunction. Here's an example (kinda from ReaConsole):

BOOL WINAPI dialogBoxFunction(HWND hwndDlg, UINT uMsg, WPARAM wParam, LPARAM lParam)
{
  switch (uMsg)
  {
  case WM_INITDIALOG:
    // Do stuff when first diplaying
    break;
  case WM_COMMAND:
    // Here's where you look for messages from your dialog controls and do something
    if (LOWORD(wParam) == IDC_EDITBOX && HIWORD(wParam) == EN_CHANGE))
    {
      // Handle stuff when user touches editbox
      // Here's how you get the text from the box
      GetDlgItemText(hwndDlg, IDC_EDITBOX, g_command, 100);
    }
    if (LOWORD(wParam)==IDCANCEL)
      // User pressed ESC
      EndDialog(hwndDlg,0); // Close dialog
    if (LOWORD(wParam)==IDOK)
    {
      // User pressed ENTER
      ProcessCommand(g_command);
      EndDialog(hwndDlg,0); // Close dialog
    }
  }
  return 0;
}

That's all there is too it. The tricky parts? Finding out what messages get sent to the dialog box function. LOWORD(wParam) is always the ID of the control (you set that in the resource editor properties). HIWORD(wParam) is the event name, just look in the MSDN for that control type. Look at the list of GetDlg... and SetDlg... win32 functions.

Hope this helps!

*edit: damn, crossposted, and way OT, sorry Tallis!

[Lawrence]

My issue would be trying to keep track of all of the parameters and (perhaps?) differing data types, I mean beyond the basic stuff.

What is wParam there? Or are those values passed by themselves from/to the API? In the above is IDC_EDITBOX a name given by the coder to the edit box or just a generic class name? Looks like Greek to me.

If I drop that code into VC++ what else would I need to make that dialog appear? I may install VC++ Express just to see how the above works.

[sws]

Originally Posted by Lawrence

What is wParam there? Or are those values passed by themselves?

Windows gives you that, defines the reason the function is getting called in the first place.

Sounds like you guys need MFC. Easier than win32, and fine for simple stuff. I'll post an example project.

[Lawrence]

I'm more than a little confused here. I understand that you can code within a C++ development enviroment to use the Reaper API, so why not just use the standard drag and drop windows controls in VC++ to create the GUI dialog windows, buttons etc for user input/choices?

http://www.functionx.com/visualc/Lesson09.htm

Or do you HAVE to be manually coding at that low level even for the gui to access the Reaper API?

I don't get it. The buttons / dialogs are just for user choices... the Reaper API stuff happens after you click a button right? User clicks a button (makes a choice) and then your code block does what it does with the Reaper API.

Can't you just create GUI dialogs "VB Style" with VC++ (drag and drop) and end up at same place you would be AFTER a user clicks a button... back in that same code block doing whatever you coded it to do with Reaper's API?

Can't you direct a response from a drag and drop GUI dialog form/control to that same code block?

I pretty sure those controls are the MFC (the foundation classes).

[Xenakios]

Originally Posted by sws

Windows gives you that, defines the reason the function is getting called in the first place.

Sounds like you guys need MFC. Easier than win32, and fine for simple stuff. I'll post an example project.

If you can do that, I would probably be very grateful.

[Tallisman]

so... ummm... you'll do it then?!!!


.t

[Xenakios]

Originally Posted by Lawrence

Can't you just create dialogs "VB Style" with VC++ (drag and drop) and get to the same place you would be AFTER a user clicks a button... back in that same C code routine doing whatever you coded it to do with Reaper's API?

No, it does not work like that exactly...The interface design is quite badly separated from the code that actually does things. It's a complicated situation, especially now that there is .NET. Because Visual Studio Express 2008 actually DOES allow the kind of form/GUI design that is possible in VB and Delphi (with the automatic event handler code generation), but ONLY for "Managed C++", which is a horror that uses Microsoft .NET.

I am so confused and frustrated about all this that, honestly, I would (almost) take the Visual Basic option myself. Much of the stuff is not so much performance critical that the relative slowness of VB would matter. Now, if only someone was able to make that bridge-DLL to the Reaper APIs functionality...

[Xenakios]

Originally Posted by Tallisman

so... ummm... you'll do it then?!!!


.t

I might look into it, no promises. But the GUI stuff has to be easier than now, to there be any chance it is me who will start actually doing your idea...

[Lawrence]

Originally Posted by Xenakios

No, it does not work like that exactly...The interface design is quite badly separated from the code that actually does things. It's a complicated situation, especially now that there is .NET. Because Visual Studio Express 2008 actually DOES allow the kind of form/GUI design that is possible in VB and Delphi (with the automatic event handler code generation), but ONLY for "Managed C++", which is a horror that uses Microsoft .NET.

Wow. What are you using, which development tool?

[Xenakios]

Originally Posted by Lawrence

Wow. What are you using, which development tool?

I've used both VC 6 and Visual Studio Express 2008. VSE 2008 doesn't really offer anything significantly nicer for developing the Reaper Extensions stuff than VC 6 (because the modern GUI design is not available for "native C++" that the Reaper plugins should use), but is a lot more bloated and slower to use.

[robg]

Originally Posted by Xenakios

No, it does not work like that exactly...The interface design is quite badly separated from the code that actually does things. It's a complicated situation, especially now that there is .NET. Because Visual Studio Express 2008 actually DOES allow the kind of form/GUI design that is possible in VB and Delphi (with the automatic event handler code generation), but ONLY for "Managed C++", which is a horror that uses Microsoft .NET.

I am so confused and frustrated about all this that, honestly, I would (almost) take the Visual Basic option myself. Much of the stuff is not so much performance critical that the relative slowness of VB would matter. Now, if only someone was able to make that bridge-VST to the Reaper APIs functionality...

This gets back to what we were discussing on the other thread. No easy option, really. There's going to be hard work involved whether you use VB or C++.

Again, my concern with making a bridge .dll, or porting a VB.net API is that Reaper is updated so often, I really don't have the time to keep up with the changes, and may not even have the time to make a bridge in the first place. I have the feeling others are in the same boat.

I was pondering suggesting the MFC option myself, but it's been so long since I've done any GUI C++ stuff, I wasn't really comfortable bringing it up. Kudos to SWS for that.

Xenakios - wouldn't it be AWESOME if they made the Windows Forms Designer work for pure C++? Wish, wish, wish... I'm sure it will never happen since it's just prettying up calling .net library classes.

Yet another option is looking at getting a 3rd party GUI library.

[Lawrence]

http://edais.mvps.org/Tutorials/CDLL/CDLLch1a.html

Any relevance (to being able to see one of those dll's in VB)?

If we keep knocking it around something may come up.

Can somebody graphically diagram how the Reaper API dll actually allows "doing stuff" with Reaper? I'm not sure I really understand how the whole thing works from A->B. Can someone sketch it out for us retards?

I've got "ReaTit.dll" in my Reaper directory, I launch Reaper... what happens next?

What happens and where (step by step for us among the slow) theoretically when the dll / api is used to do something with Reaper?

[Xenakios]

Ok, this is getting toooo much off topic, maybe there should another thread about "The Horrors of GUI-programming for beginners" or something...

[Xenakios]

Originally Posted by Lawrence

http://edais.mvps.org/Tutorials/CDLL/CDLLch1a.html

Any relevance (to being able to see one of those dll's in VB)?

If we keep knocking it around something may come up.

Can somebody graphically diagram how the Reaper API dll interfaces Reaper? I'm not sure I really understand how the whole thing works.

Can someone sketch it out for us retards?

What happens and where and when theoretically when the dll / api is used to do something with Reaper.

Reaper expects only ONE function to be in the extension DLL and uses only that function. This really is the difficulty about the whole thing about using other languages for creating the plugins.

int REAPER_PLUGIN_ENTRYPOINT(REAPER_PLUGIN_HINSTANCE hInstance, reaper_plugin_info_t *rec)

So when Reaper tries to load a DLL, it looks for that function in the DLL, and if found, it calls it. Inside the function is now the plugin spesific code like :

g_hInst=hInstance;
  if (rec)
  {
    if (rec->caller_version != REAPER_PLUGIN_VERSION || !rec->GetFunc)
      return 0;

    *((void **)&InsertMedia) = rec->GetFunc("InsertMedia");
    *((void **)&GetMainHwnd) = rec->GetFunc("GetMainHwnd");
    *((void **)&GetProjectPath) = rec->GetFunc("GetProjectPath");

This seems pretty much like something that is impossible to replicate in VB/Delphi/Cobol...(Kidding about Cobol.) I actually think I figured out the reason WHY it is impossible earlier today, but can't remember any more...

What happens there is that for example the function InsertMedia is loaded from Reaper via the variable "rec". (I maybe technically wrong about this, but it's along those lines.) After the function is loaded, it can be used by the actual plugin code. So to be able to use these from VB/Delphi/etc, some pretty serious "magic" would have to be done.

edit : Oh, sorry this wasn't explained with a drawing.

[sws]

Originally Posted by Lawrence

I've got "ReaTit.dll" in my Reaper directory, I launch Reaper... what happens next?

Btw, your DLL needs to be named "reaper_*.dll"

[Justin]

Originally Posted by Xenakios

This seems pretty much like something that is impossible to replicate in VB/Delphi/Cobol...(Kidding about Cobol.) I actually think I figured out the reason WHY it is impossible earlier today, but can't remember any more...

Hmm no, exporting the function to REAPER, and indeed querying/calling the REAPER APIs should be very possible in VB/Delphi. If I knew these languages more I could describe how. But the one exported function isn't too dissimilar from VST, and people can make VSTs in Delphi apparently.

The stuff that's C++ specific would be if you want to implement or use more advanced things, specifically accessing C++ classes that are in reaper_plugin.h

-Justin

[Xenakios]

Originally Posted by Justin

Hmm no, exporting the function to REAPER, and indeed querying/calling the REAPER APIs should be very possible in VB/Delphi. If I knew these languages more I could describe how. But the one exported function isn't too dissimilar from VST, and people can make VSTs in Delphi apparently.

The stuff that's C++ specific would be if you want to implement or use more advanced things, specifically accessing C++ classes that are in reaper_plugin.h

-Justin

Hmm, interesting, so at least some of the basic functionality could MAYBE be accessed by a DLL that was directly compiled in Delphi/VB. (I don't know if VB can actually even make DLLs itself, heh...Forgive me my ignorance, Lawrence. )

This could be worth investigating for a few hours, then. If I can make it work from Delphi, then it would not be a too big stretch (I think) to make it work with VB, also. (Assuming VB actually has the facilities to create reasonably standard Windows DLLs. Well, and the ability to have pointers to functions is needed, too*.)

edit : * For Lawrence. This means you would have to be able to declare VB subs (for Reaper API functions that don't return a value, that is a "void" function in C-speak) and functions, without actually writing any code for them yourself. Rather you would assign an address to these functions by using something like : TheReaperFunction = @TheAddressToTheFunction. (Works in Delphi somewhat like that.) The address having been returned from Reaper. The "TheReaperFunction" would now be callable with whatever arguments the function was declared with, for example TheReaperFunction(NewEditCursorPosition, False, False).

[manning1]

Xen.
i left programming years ago , n did too much code in my time,
thus dont wanna do it anymore.lol.
just wanna draw your attention to something.
but a neat little compiler i came across is called ibasic.
the beauty of this compiler is no dam big run times needed,
and compiles to stand alone exe's. all the standard vb type basic commands are there with some of its own .
(i think you can also use win api's. but check.)
another is purebasic.com. same deal no big run times.
if i remember one or both also handle in line asm for the hard core guys.
the reason i mention these compilers and noting the gui aspects ,
it might be interesting (but mebe i'm wrong.....)i feel if a collab occurred maybe ...
tween reap n these compilers.
cos if i remember its real fast in em to throw up user dialogs etc etc. no mfc required etc.
i was just wondering if there was a way to use say purebasic for the front end user interraction and mebe more interfaceing with reaper for plug in development by a user who has "some" programming skills. i mention all this cos it might be interesting , but i dont know daw programming , so i might be wrong.
only reason i mentioned it is i was wondering if there was a way
to help people interested in doing their own plug ins for use in their reaper daw but who might find C++ daunting to learn.
obviously justin is a C++ guru.
but the language is a challenge for lots of people.
so i was just wondering bout alternatives for folks who might like to do their own plug ins.
no flames please....its just ideas i'm floating.

[Lawrence]

Originally Posted by Xenakios

Hmm, interesting, so at least some of the basic functionality could MAYBE be accessed by a DLL that was directly compiled in Delphi/VB. (I don't know if VB can actually even make DLLs itself, heh...Forgive me my ignorance, Lawrence. )

Yes, you can compile dll's in VB. I've never actually done it but that is one of the project templates.

Interestingly enough, if one can get a *working* Reaper dll loaded in VB and actually use it's function(s) *from within VB* (or with VB created apps), it's not a stretch to think perhaps one can then *wrap that code into an Active X / OCX custom control with VB*. Passing the function properties and/or methods to the active X control at a higher level?

Not that I have the personal skill to do that from A to B... theoretically speaking.

But would not that be nice?

This could be worth investigating for a few hours, then. If I can make it work from Delphi, then it would not be a too big stretch (I think) to make it work with VB, also. (Assuming VB actually has the facilities to create reasonably standard Windows DLLs. Well, and the ability to have pointers to functions is needed, too*.)

Uhmm.... dunno. Everything I've read about creating dll's in VB (which is not much) suggests that is the case.

Edit: Actually I think they're called "ActiveX dll's", so I don't know if that has any relevance to your question.

edit : * For Lawrence. This means you would have to be able to declare VB subs (for Reaper API functions that don't return a value, that is a "void" function in C-speak) and functions, without actually writing any code for them yourself. Rather you would assign an address to these functions by using something like : TheReaperFunction = @TheAddressToTheFunction. (Works in Delphi somewhat like that.) The address having been returned from Reaper. The "TheReaperFunction" would now be callable with whatever arguments the function was declared with, for example TheReaperFunction(NewEditCursorPosition, False, False).

Huh?

I'd like to give it a shot once I can wrap my tiny bird brain around it.

KEEP HOPE ALIVE!

[Lawrence]

Originally Posted by sws

Btw, your DLL needs to be named "reaper_*.dll"

I thought "Rea_Tit" had a nice ring to it... but I'll remember that.

[bullshark]

Originally Posted by Lawrence

I thought "Rea_Tit" had a nice ring to it...

Yeah, seems to roll nicely off the tongue for some reason, even for a frenchman like me.

[Lawrence]

Originally Posted by bullshark

Yeah, seems to roll nicely off the tongue ....

That would be "Rea_Nipple".

Sorry, I could not resist that opening...

[Lawrence]

Originally Posted by Justin

The stuff that's C++ specific would be if you want to implement or use more advanced things, specifically accessing C++ classes that are in reaper_plugin.h

-Justin

Maybe related.

Calling C++ routines from VB.net

http://forums.microsoft.com/MSDN/Sho...93905&SiteID=1

Parts II and III below...
Calling a DLL C++ class from a VB application

http://www.codeproject.com/KB/DLL/XDllPt3.aspx

When I Googled access C++ classes from VB I got some hits. Not that I actually understand how much of it works.

VB.net Example

Public Class MyClass
<DllImport("Rea_Nipple.dll")> _

Private Shared Function SquareRoot(ByVal value As Double) As Double

End Function

Public Function SqrRoot(ByVal value As Double) As Double
Return SquareRoot(value)
End Function
End Class


Finally, there appears to be a way to call unmanged API's from managed classes

http://msdn2.microsoft.com/en-us/lib...04(vs.71).aspx

[bullshark]

Originally Posted by Lawrence

That would be "Rea_Nipple".

Sorry, I could not resist that opening...

I was going to say that "Rea_Nipple" would be the perfect companion for "Rea_Lick" but, for the sake of not drifting too much off topic, I won't

[Lawrence]

I've been trying to get VBE 2008 to run on my Vista laptop and I've hosed it up like 4 times and had to reload from a restore point each time.

I finally got it *running* by manually fixing the registry permissions one at a time, and then my audio card shut off and none of my services wouldn't run... including system restore. If not for the magic F8 button I would have been totally hosed.

I give up. Anything I do with the Reaper API will be on XP on the desktop.

Jesus Christ Microsoft!