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