Hello, I have made an abstraction called "Key" to easily manage keyboard shortcuts in pd, but everytime that I load a patch containing the abstraction I get this error for every instance of the patch that is loaded:
load_object: Symbol "Key_setup" not found
what can cause this? My abstraction has two creation arguments and I get the error even if they aren't used. Any ideas?
However this is the patch:
Key.pd

Hi,

I tried using your abstraction in another patch and it loads without any problems on my computer and no error messages are displayed. Sorry but I have no idea what may be wrong on your side...

Take care,
Gilberto

PS: nice abstraction by the way!

I get the error even if I change the arguments of the abstraction, you could try this?

P.S.: Thak you, when it will be ready I will post a project that I'm making to simplify keyboard interaction in pd

Hi,

I created a patch with several instances of your abstraction:

[Key] <- just testing
[Key a]
[Key a 1] <- just testing as well, I understood that the second argument can be only t, r or s
[Key a t]
[Key a r]
[Key a s]
[Key 1] <- for some reason this one does not recognize the key 1 being pressed 
[Key %] <- nor does this one [EDIT: this does work!]

Everything was running exactly as expected. I then changed the creation arguments of several of them and all of them were doing well. At no moment an error message was displayed.

If you want me to test anything else, just let me know. And I am glad to hear you plan to share the final object here, it looks like a nice addition!

Take care,
Gilberto

I'm using the latest version of pd extended under Windows 8.1, whats OS are you running?
I'm aware that there's a problem with numbers because the symbol object doesn't pass them I think because it interprets them as floats and I'm trying a workaround, if you have any idea about this I would be happy to know it.
Thank you for your cooperation

works on my win7_x32 mashine.
cheers

@Patcher88 I am running Linux and pd-extended (64 bit). I also have Win 8.1 on my machine, if you want I can boot on it later and give your abstraction a go, but it looks to me that your problem has more to do with your pd installation or configuration than with the system (particularly now that @bang confirmed it works on his Win 7).

And after digging a bit more, it looks like key_setup is the part of Pd's code where the three objects [key], [keyup] and [keyname] are defined (line 370, http://sourceforge.net/p/pure-data/pd-anywhere/ci/master/tree/src/x_gui.c ) but I don't know how does this relate to your case.

Do these three objects work well with your installation? Do you get any errors when using them?

Yes the objects work well, note that my abstraction is called Key with the upper case, and Key is with the upper case also in the error, so I don't think that is related with the standard objects. If you could try the abstraction also in Win 8.1 I will try to wip my pd installation if it works well on your machine. Thank you

Hi @Patcher88,

So I booted up my Win 8.1 and I created a patch that uses your abstraction, and I got the same error message as you did! But I found a way of getting rid of it: simply rename your abstraction from [Key] to anything else! My suspicion is that there is a conflict between [key] and [Key], and this is only happening in Windows because very often it doesn't recognize difference in capitalization (in Linux and Mac, capitalization always matter). So I am not sure my explanation is correct, but nevertheless the solution certainly is, give it a try.

I'm aware that there's a problem with numbers because the symbol object doesn't pass them I think because it interprets them as floats and I'm trying a workaround, if you have any idea about this I would be happy to know it.

If something crosses my mind about this issue, I will let you know.

Take care,
Gilberto

And this link might give you some ideas about your problem (read the section under Important note about "exotic" words): http://puredata.info/dev/PdMessages

Or still, what about this?

Since the problem is that [$1] only take floats and [symbol $1] only take symbols (and it is impossible as far as I can see to give an argument that consist of a digit but that in reality is a symbol, not a float), then why not avoid the creation arguments completely and let the user select the key himself with some sort of algorithm as the one above? That's an idea.

Take care,
Gilberto

@gsagostinho said:

Hi @Patcher88,
So I booted up my Win 8.1 and I created a patch that uses your abstraction, and I got the same error message as you did! But I found a way of getting rid of it: simply rename your abstraction from [Key] to anything else! My suspicion is that there is a conflict between [key] and [Key], and this is only happening in Windows because very often it doesn't recognize difference in capitalization (in Linux and Mac, capitalization always matter). So I am not sure my explanation is correct, but nevertheless the solution certainly is, give it a try.

Thank you for the answer! After your message about the key error where I've answered that my abstraction used capital letter I've made the same thoughts as you about and I've tried to change the abstraction name and it worked perfectly, and this morning I've read your answer! Thank you very much!

@gsagostinho said:

Since the problem is that [$1] only take floats and [symbol $1] only take symbols (and it is impossible as far as I can see to give an argument that consist of a digit but that in reality is a symbol, not a float), then why not avoid the creation arguments completely and let the user select the key himself with some sort of algorithm as the one above? That's an idea.

I will try your solution, but the thing that I cannot explain is that pd object "keyname" if you attach a print object to it prints exactly "symbol 1" if I press the key number but I cannot achieve the same result. I will try something and let you know. Thank you

Hi, I am glad to hear you solved your problem!

I will try your solution, but the thing that I cannot explain is that pd object "keyname" if you attach a print object to it prints exactly "symbol 1" if I press the key number but I cannot achieve the same result.

I do not understand very well what you mean. [keyname] always prints symbol <keyname>, where symbol specify the type of that information. You could also specify the type of a float in another situation - for instance, both examples below print the same result:

[3(             [float 3(
|               |
[+ 2]           [+ 2]
|               |
[print]         [print]

The fact that [keyname] always specify that it is outputing a symbol is good for you, since you can use number-looking symbols without making Pd think they are of the wrong type. So you can feed directly what [keyname] is outputing to a [sel s] and it will work for numbers, letter, etc.

Take care,
Gilberto

@gsagostinho said:

I do not understand very well what you mean. [keyname] always prints symbol <keyname>, where symbol specify the type of that information. You could also specify the type of a float in another situation - for instance, both examples below print the same result:

[3(             [float 3(
|               |
[+ 2]           [+ 2]
|               |
[print]         [print]

The fact that [keyname] always specify that it is outputing a symbol is good for you, since you can use number-looking symbols without making Pd think they are of the wrong type. So you can feed directly what [keyname] is outputing to a [sel s] and it will work for numbers, letter, etc.

Take care,
Gilberto

I was meaning that if I attach to the right outlet of the object [keyname] a [print] object it outputs: "symbol 1" when pressing number 1 on the keyboard and I don't understand why if an object can output a float as symbol I can't do the same by creating a message box [symbol 1(...
By the way, I think that I've found a workaround to use the abstraction always with two arguments, right now I'm debugging it; I've already fixed two problems caused by the last edits but now everything seems to be ok. I've attached the new version if you or someone else wants to try it.
Kbd.pd

Hi,

Now I understand what you meant before. Indeed Pd does not recognize [symbol 1( and I don't know why...

About your new version, it kind of works, but I have a couple of problems with it. Firstly, I get the following error whenever I have a non-float argument:

Bad arguments for message 'f' to object 'objectmaker'
 f $1
... couldn't create

But I see that this won't be possible to correct, since you are using both [f $1] and [symbol $1] at the same time. That's a clever way of using either type as your argument, but the price to pay is to have the ugly error messages appearing.

Here are some more bugs:

• [Kbd 1 t] works well, but [Kbd 1 r] activates only once
• if I have both [Kbd b t] and [Kbd a r] in the same patch, then I hit first the key b (so far so good) and then I hit the key a, the object [Kbd a r] will ignore this hit. But then if I hit a once again, it will then behave normally

Take care,
Gilberto

@gsagostinho said:

But I see that this won't be possible to correct, since you are using both [f $1] and [symbol $1] at the same time. That's a clever way of using either type as your argument, but the price to pay is to have the ugly error messages appearing.

I've noticed the error immediately after I've uploaded the patch and now I've fixed it using [any] instead of [symbol] and [float] Kbd.pd

@gsagostinho said:

Here are some more bugs:
[Kbd 1 t] works well, but [Kbd 1 r] activates only once
if I have both [Kbd b t] and [Kbd a r] in the same patch, then I hit first the key b (so far so good) and then I hit the key a, the object [Kbd a r] will ignore this hit. But then if I hit a once again, it will then behave normally

I will investigate further those bugs and let you know, thank you!

now I've fixed it using [any] instead of [symbol] and [float]

I didn't know about [any], that's fantastic!

I will investigate further those bugs and let you know, thank you!

My pleasure, take care,
Gilberto