I created three clickable keyboard objects that may be handy when dealing with MIDI. They can also be used to visualize MIDI data coming in. See:

NEWEST VERSIONS:

For Pd-extended: keyboards-pd-extended.zip
For Pd-l2Ork (the current build in their website is a bit old and you may need to compile it from source in order to use it: as far as I remember, the pre-compiled .deb build available in their website still does not allow images to be clickable, but I may be wrong with that): keyboards-pd-l2ork.zip

Please note that these do not work on Windows as they rely on moonlib's [absolutepath], which isn't available for neither Windows 32-bit nor 64-bit.

I hope you all will enjoy it!

Take care,
Gilberto Agostinho

On the bright side, it's easy to compile a Fortran code. I never did it on Mac, but it should work the same way: using a program named gfortran (best Fortran compiler), navigate in the terminal to the source code folder and type: gfortran configure.f95 -o configure. This will create a file named configure which should work on your computer. So now you replace the Linux one inside the folder keyboards, copy this whole folder to its final destination (somewhere where you normally put your external objects) and then run the configure file you just created. Now open Pd, add this folder to the path and restart. That should be all!

Let me know if it works for you. Take care,
Gilberto

I never did it on Mac, but it should work the same way: using a program named gfortran (best Fortran compiler), navigate in the terminal to the source code folder and type: gfortran configure.f95 -o configure. This will create a file named configure which should work on your computer. So now you replace the Linux one inside the folder keyboards,

Take care,
Gilberto

I believe I found a way of avoiding to use an installer, now you can simply copy these abstractions to any folder, add it to Pd's path and that should be all!

Here is the new version: keyboards.zip

Some few notes about it:

• I tested with pd-extended and Linux 64-bit. I would appreciate, in case you give them a try, to let me know if they work on your system
• Potentially this will work well on any Linux distro and OS X, as well as 32-bit and 64-bit
• As for using Windows, that may be a problem because the paths in Windows use backslashes \ such as C:\folder\file, whereas both Linux and OS X uses opposite slashes / such as /folder/file, and the location of the images is important for these objects to properly work. That said, if some Windows user would have the interest, I wouldn't mind creating a Windows version

Best,
Gilberto

I fixed some bugs with this keyboard, and I also created a Pd-l2Ork version of it. You can download them from these links:

Pd-extended version: keyboards-pd-extended.zip
Pd-l2Ork version (the build in their website is a bit old and you may need to compile it from source in order to use it: as far as I remember, the pre-compiled .deb build available in their website still does not allow images to be clickable, but I may be wrong with that): keyboards-pd-l2ork.zip

Best,
Gilberto

1. (Not Very Important) )When I create the [keyboard] object, this prints to my console:
   (Tcl) UNHANDLED ERROR: couldn't open "/usr/lib/pd- extended/extra/ggee/logo100.gif": no such file or directory while executing From your video on vimeo, it looks like you're running Linux, and so this is probably the correct directory for you. On OS X, the extra can be found in /Applications/Pd-extended.app/Contents/Resources/extra/ggee, although I'm not sure why this is important because it is just the Tcl/Tk logo haha.

2. (Very Important) When I create any of the keyboard abstractions, the left outlet does not seem to work. Without even having pressed a key, a number box connected to the left outlet will only display the number '59' for me. Even when I click on any of the keys, the correct number will be spit out the left outlet, only to replaced by '59' a split second later. I've tried looking into the abstractions, but I am baffled because everything seems like it should work. I'll do some more digging tomorrow to see if I can find what the problem is.

• the error couldn't open "/usr/lib/pd- extended/extra/ggee/logo100.gif" seems to be related to the object [image] itself and not to my abstraction here, as I don't use any logo100.gif and also this file is (or should be) located in the extra folder. This is a pd issue as far as I can see.
• it's really strange that you guys are having this left outlet problem, here on my Linux I never saw that. I will have a look on it as soon as I can. But maybe could you guys check if there is any object missing (red squares) in those abstractions?

Take care!
Gilberto

I finally had some time for testing this, and I have to say I still don't know why this isn't working on Windows. I see that @whale-av has removed [moonlib/absolutepath] from my abstraction openPath.pd, and so maybe the / is the cause of the problem.

The thing is, although I can't really test this on Windows, I don't believe David's solution above is correct: without the absolutepath, the keyboards will only work if you copy them into your project, but they won't work if you simply add them to your pd path. This is because [image] is a very silly object and it needs either the absolute location of an image (annoying as people install it in different places on their systems) or it will use relative paths to the currently opened main patch, and not to the abstraction using it. This is why I used the [absolutepath] trick there.

So can someone under Windows make a little test for me? Could one of you please open openPath.pd in the abstractions folder and use [moonlib\absolutepath] (with \ instead of /) or simple use [absolutepath] and see if the keyboard works? Also, for this test, please don't copy this abstraction to a project folder and use it locally but rather add it to your pd abstraction/external folder and see if you can create a [leyboard] in a new and unsaved project.

@whale-av did you modify anything else than openPath.pd? I ran all those files through a diff checker and I couldn't spot any other modification, but I did this manually and so I might have missed something.

Thanks to you all and let me know, please. Cheers!
Gilberto

Thanks a lot for the help, David!

@whale-av thanks again for the help troubleshooting this abstraction!

Windows has a different notion of paths to unix-like systems, including drive specifiers.

The first line of moonlib/absolutepath.c[1] is

#ifndef _WIN32

so the file is empty when compiling for Windows. (Perhaps it could contain an alternative implementation that prints a more > useful error message.)

The non-Windows implementation uses dirname() from libgen.h, which isn't available on Windows as far as I can tell. A suggested alternative is _splitpath_s[2].

[1] http://sourceforge.net/p/pure-data/svn/HEAD/tree/trunk/externals/moonlib/absolutepath.c#l1
[2] https://msdn.microsoft.com/en-us/library/8e46eyt7.aspx

So in that case, these are not Windows compatible I am afraid...

from then on it is good every time that you open your "containing" patch, so no problems with broken cords.

and so it works. I would like to make it perfect, so I will work on it when I can.
It could be possible to get a "map 0, map 1" into it but I cannot yet figure that out for this scenario.
For the time being......... gilberto_keyboard.zip
David.

I adapted @gsagostinho keyboards to run on pd-vanilla. I used @whale-av openPath.pd, changed some objects for vanilla compatibles and add the external objects of ggee and cyclone necessary to run with no matters in vanilla.

keyboards-pd-vanilla.zip

Hope it works!

Cheers!
Gilberto