I do have a pretty old midi footcontroller here, that I'm trying to connect to "renoise". The problem is, that renoise doesn't accept program change commands to control it's functions but just to play the instruments you've programmed. However, I'm trying to write a routine that just translates the program change numbers into control changes. That didn't seem too hard at first but now I've stumbled over a nasty problem.
When I hit the mf-1 it always sends the midi command twice and seems to get confused when I press one of the knobs twice as well. Any suggestions?

Midischaltzentrale-V2.pd
In the patch I've just connected the pgmin to the ctlout. I don't need any special value on the knobs, so I gave it 127 as standard.

Hi,

When I hit the mf-1 it always sends the midi command twice

Which kind of MIDI data do you receive when the foot controller is fully pressed and when it's fully released? Very likely you need to do something about not sending data when the foot controller sends a zero. See this thread for some inspiration: http://forum.pdpatchrepo.info/topic/9353/ignore-velocity-of-trigger-pads/11

Cheers,
Gilberto

Midiparse just realizes program changes. To see if it really does anything when I unpress the button I was putting bangs on every "cable" in the patch. It seems to do nothing when I let loose of the knob.
I already fumbled around with [change] but it didn't work either. It just made me press the controller three times to send a control change message.

It's very difficult for me to understand the problem without understand exactly how this pedal behaves. To see which sort of numbers pd is receiving, just check the number boxes connected to [pgmin] that you have in your patch.

Try using [alternate] for that.

This seems to work!
Midischaltzentrale-V2.pd
I just don't know why.

Anyway, I'm trying to make one of the knobs do the play AND stop function now. I thought it might be the same routine as in the named trigger patch. But the problem is to seperate the one knob from "all the others" in that case. I'm trying to do this by using [select] which doesn't do quite what I want. I would need an object that sends the value to one output if it's true and to another if it's false.
I've even combined the trigger patch into this one here:
Midischaltzentrale.pd

@gsagostinho
pgmin just receives 10 and the channel number, nothing more. It's a very old pedal and doesn't do any more magic.

@kitchens A couple of things:

• you don't have to delete your posts to change something, you can simply edit them. I had already answered your previous one and now the thread got quite confusing.
• did you try to use [alternate] as I recommended or are you still having troubles? I really can't follow what you are doing unless you tell me about it. Anyway, I really think this object will be ideal to create something like "click one time to do A click another time to do B and so on".
• about receiving only the value 10 and the channel number: that has already been solved, right? I mean, it is working right now, right?

Cheers,
Gilberto

I'm sorry, I have not seen the post as I posted it.
So the status is: If I use the very basic version (Midischaltzentrale-V2.pd) it works.
When I try to make the one knob do two things it gets confusing. So far the status is this patch:
Midischaltzentrale_advanced.pd

No problems.

When I try to make the one knob do two things it gets confusing

I don't understand what is confusing. When your patch receives a number 10, the alternate is working. When receiving anything else, it's just being ignored.

Well it should pass the command on when it's anything else than 10 (10 is the knob that does two things). Which is what [select] does if I got it right. So all the other commands except 10 should be passed on directly to the ctlout.
I don't know why, but it seems that it always sends the last command I gave twice no matter what the new command is. So if I press 10 it either sends 10 or 9 (which is fine), but when I press 19 afterwards it sends 9 or 10 again before it sends 19. So confusing.
I'm trying to tackle this problem for hours now. I need a break. Comming back tomorrow.
Thanks for your help dude! If I finally have a solution I will post it here.
... or maybe you can guess one while I'm away.
Cheers!

So if I press 10 it either sends 10 or 9 (which is fine), but when I press 19 afterwards it sends 9 or 10 again before it sends 19. So confusing.

Yeah, I think I know what is going on. You are not using triggers in your patch. I was going to mention it, but since you said it was working I just kept my mouth shut. Do you know how triggers work and how is the order of operations in Pd?

Basically you should never connect two or more patch cord from a single outlet without a trigger if you must receive them in a specific order. I would suggest then a cleanup of your patch, that should solve your issue.

Cheers,
Gilberto

@kitchens Hello Kitchens...
I have said it before and I will say it again (and its nothing personal... you could not know unless somebody tells you!)
Everybody.... absolutely everybody that wants to "code" Pd must read this first (apart from the last chapter (2.9) which is very interesting, but very difficult and unnecessary for most users :

http://puredata.info/docs/manuals/pd/x2.htm

Otherwise you are just fumbling around in the dark!..... which is fun!...... but very un-productive.
David.

yes, its a execution order thing.
Better try to patch the things clear and readable.
Use [trigger] as much as you can.
cheers

midi-schaltzentraelchen.pd

@gsagostinho
I think I know the order of operations, but I don't know very much about triggers.

@whale-av
Actually I think I've read that once. The problem is that I'm not coding in PD daily. So things get lost sometimes.

By the way, I get the feeling the problem is how I understand the function of the patch. I coded it as kind of a forwarding device rather than a conversion of digits and symbols.

I think I know the order of operations, but I don't know very much about triggers.

That document that David recommended you explains how triggers work. They are absolutely fundamental to the order of operations.