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

@maya628 Hi, you quoted me but wrote nothing about it. Did you mean to write anything else?

Take care,
Gilberto

Hello all,

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

Hello all,

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

@gsagostinho Hello. This seems like a very handy patch. Just wanted to let you know of some issues I have run into trying to use it. I am using extended 43.4 on OS 10.9

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.

Looks good, Gilberto. I'd made a smaller one myself, so was keen for a larger one. On Windows, many of the connections are missing! and many objects need redrawing to make connections - weird. Anyhow, it got too hard..
rjp9 - I removed extra path specs in the abstractions so just the name appeared, and put all files in the one folder, and that sorted it.
cheers

@rjp9 @RolandTpd Hi guys, thanks a lot for the reports. Right now I am participating in a festival and I barely have any free time. But I will have a look at this as soon as I can. Just some comments though:

• 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

@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