Hello all,

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

Just to let you guys know, apparently moonlib's [absolutepath] is broken for Windows, which is causing these problems. I sent an e-mail to the list to see if they know any solution to this problem. I will post any updates on this thread.

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

Got an answer from the mailing list, by Claude Heiland-Allen:

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...

@gsagostinho Woof!!
Nearly there for windows......
In extended [getdir] is available so replacing [openPath] (in the abstractions folder) with this openPath.pd
will give you the object.
When you create it you get a mess, but the next click anywhere in the window gives the desired effect!..........

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.

@whale-av Thanks a lot, David. Let's see if one of us (or someone else) can come up with a solution that hides the "entrails" of my abstraction

Hello guys!

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!

@emviveros Thanks for doing this! I still didn't have time to check it, but I'm happy with the work. Just one thing, in the README you wrote my name as Guilherme Agostinho, but I am actually Gilberto Agostinho (though this isn't a big deal, just saying it)

Cheers!
Gilberto

Hmm, just tried opening the help file in vanilla, but I got a plethora of errors due to the externals being 32-bit and my vanilla being 64-bit. Probably the best thing would be to release two versions, one for each architecture.

@gsagostinho hahahaha Gilberto sorry for Guilherme ...

I use externals binaries included in deken, but we have only linux 64 bits versions of ggee and cyclone compiled there. So I did only Linux 64 bits version of keyboards GUI, if someone have these libraries compiled in 64bits on MAC and/or WIN, please include binaries in the 64 bits version.

ps.: @gsagostinho are named correctly now.

32 bits (Linux, Windows, Mac):
keyboards-pd-vanilla-32bits.zip

64 bits (Linux Only)
keyboards-pd-vanilla-64bitsLinuxOnly.zip

Cheers

Thanks a lot! Cheers!