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

@gsagostinho Hello Gilberto, et al @RolandTpd @rjp9 ..... woof!
I have a vague recollection of having posted a fix for win7 pd.43extended during the previous blackout but one, with an explanation of what I had modified. However I can't remember what needed fixing. I do remember it not working though.
Here is my 100% working (on my laptop) version..........
gilberto_keyboard.zip
David.

@whale-av Thanks David! I will check it soon

I haven't tested it but it looks great!!

Hi all,

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

@gsagostinho Hello. I had missed that it should be added as a pd lib... sorry. Slowly it is coming back to me..
In windows extended [absolutepath-help] cannot create [absolutepath] or [relativepath] with the messages "absolutepath_setup not found" and "relativepath_setup not found". So I assume that it is broken.
Also we cannot type \ (even in a comment!)........ we get "keycode92: dropped.
I will look for another solution as well, so that it can be used as an object........
David.

@whale-av what about adding a [import moonlib] to the openPath.pd abstraction and using only [relativepath]? If that works, I will simply exchange that abstraction so that it will work for both Linux and Windows (and probably OS X), without people having to bother which OS they are on.

Thanks a lot for the help, David!

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!