Im working on being able to use a much simpler floor board for controlling Live. This means individual switches need to do more work. Now Im (more) comfortable with abstractions, I have given it my best shot but Im stuck with inconsistent function. There is a standard time of 500ms (call it Timer for the following description) for the following behaviours (using 4 outlets)

1. Quick click (ie pedal down, pedal up <Timer) : Outlet 1 sends a flag of 0
2. Click and hold (waits for pedal up) : Outlet 2 sends a flag of 1 to indicate pedal still down and a flag of 0 when pedal released
3. Quick click plus a pedal down and hold: Outlet 3 sends flag of 1 to indicate waiting pedal up and 0 to indicate released
4. Double click < Timer : Outlet 4 sends a flag of 0

When the sustained pedals are released, they need to bypass the timer and fire immediately.

The trouble Im having is working out a flag to store/indicate pedal is held but then routing it so that when a pedal up is received, knowing if it should release the 2. or 3..

Any help greatly appreciated...Im sure it must be simpler than my spaghetti....
PB_01.pd

@image_engine Not quite understanding clicks and pedals...... I made this that will step through the outlets and might help....... pedal.pd
pedal press.... out1
double-press... out2
triple-press... out3
etc.
Instant release (to zero) for pedal "up".
It might help if you can merge it with the "clicks"?
David.

thanks @whale-av
Sorry if it was a bit hard to understand.

Speaking in bangs (pedal up or down = 1 bang as well)
1 bang = pedal down...wait eg 500ms sec = val of 1 sent to outlet 1 and pedal up (another bang) sends val of 0
2 bangs (pedal down then up)<500ms should send val of 0 to outlet 2
3 bangs <500ms should send val of 1 to outlet 3 and val of 0 when pedal is released (bang after 500ms)
4 bangs in succession < 500ms sends val of 0 to outlet 4

Case 1 seems to function but I think the rest is not as I was hoping it would work. All the outlets seem to bang regardless of click type as well
Cheers
Mark

How can you separate 2 from 3 or 4, since all use a pedal held for < 500ms. If you hold the pedal for this amount of time, as soon as you release it, Pd will get a <500 value out of [timer]. If you want to use successive pedal presses, Pd should wait for a specified amount of time before deciding what to do.
For example, if you want to use a single pedal press for <500ms, and two successive pedal presses for <500ms, you should set a time threshold in between the successive presses (like 500ms). So, with a single press, 500ms after you release the pedal, if you haven't pressed it again, Pd will go for one option, and if you press it again within these 500ms, Pd will go for the second option.
The point is, Pd can't foresee the future and know if you will press the pedal again or not.

Still not sure if the behaviours are understood.
@alexandros Only 1 and 3 have a held down state possible. The counter tallies the number of bangs within the interval and I use that as a flag so when pedal is released, it knows which output and value to use. I ended up getting it going...any help in cleaning it up would be great or better ways to achieve the same. Basically it has 2 forks depending on the flag value

@image_engine Upload please...... we cannot see the send/receive messages in objects.
David.

I admit I have a long way to go with styling...commenting is hard work in pd

PB_01.pd

Is there a problem with W10? I did all the dev on this w8 lappy and moved it on to identical setup on w10 surface...I run pd...all good...as soon as I boot Live, the buttons on pd are erratic and its so simple I cant see any midi feedback loops etc?

@image_engine GUI "lag" is due to incorrect audio settings.
You probably need to increase the buffer....... Delay (msec).... in the "Audio Settings" menu.
You will have more audio latency but the GUI should respond properly.
Here is your patch "tidied".......
It should be easier to read, but as I have redrawn some cords it might not work as expected (order of operations). You should put in some triggers to force the correct order of message sending. Any error is likely to be at the first and third outlets of [sel 1 2 3 4] or the bang connected to the first outlet of [sel 1 2 3 4]..
ped1.pd
David.

Thanks David,
GUI prob: I'm not using audio in pd at all...midi only and the 2 machines are mostly the same except w8 vs w10. The console window does bring an error up on the w10 on open of the file...
input event_
could not create
So I used old school deduction ie continually halving the file until its located, not realising you can just use the find tool...doh (although the error is not the actual name of the objectd). So it seems that input_event seem to be broken on w10? I have the same 0.43.4 extended on both

Commenting the s & r makes sense. I didn't think the execution order mattered too much as each action type is mutually exclusive until the pedup flag is reset.

Q: just before outlets 2 and 4, you have inserted bangs...why is that...to keep visual debug? Doesn't sel send bangs from successful outlets? Just trying to make sure I understand. I had bangs off the sel purely as a debug tool...is there a better way to visually debug?

Also, is it better to use a symbol or a float to store a constant ie sel 1 3 is using a number 0 to reset the checkbox...what is the better reset atom?

Really appreciate your excellent advice!

@image_engine I have absolutely no idea why it should be the case...... but the GUI will be laggy if the audio settings are too tight........ even when the DSP is not in use AND IS TURNED OFF. It makes no sense, but it is so. Maybe an audio chain is built as the patch is built, even when there are no audio objects?

[input_event]...... I might be wrong, but my foggy old brain is trying to tell me that [input_event] was not part of extended. If you have made a fresh installation on W10 it might be missing.
Here it is again from my "pd/extra" folder........ in.zip
The two files were in "extra"...... not in a sub-folder.... which makes me a little more certain that they were not included in extended.
Of course the Win 10 api might have been re-written and the .dll might be deprecated.

I don't know if the execution order is critical for the pedal up flag...... but that would be the first place to look if the patch behaved badly. It could matter if you changed something else for some reason. But on the left side the send_ped_up can send [0( from the box above when banged by [sel 1 3] and [1(...[1( or [0(....[1( depending on the order from [sel 1 2 3 4]. Can that cause problems because of the arrival of a new input in the middle of a pedal input? I don't know...... but it could be best to "fix" the order so that there is no doubt about the logic.

Yes, I inserted the two bangs to get rid of the double cords from the select object...... but also, as you say, it helps with a de-bug...... as it reminds the reader that outputs 2 and 4 are getting only bangs, while outputs 1 and 3 are getting logic (0/1).......

I would use logic (0/1) as you have done....... as the patch is all about logic. Number 0 is logical false and so "means" "off" and is a natural reset. You could create tags for messages using symbols and then [route] instead of [select]. I had never thought about that, but it is a very interesting idea . It serves no purpose in a running patch, and creates extra work building the patch........ BUT......
..... In the past I have set a slow [metro] to make such a patch "live" and used "magic glass" or labelled [print] objects for debugging. In a very complex logic patch it could be very useful to tag the messages. It can be hard to spot message ordering problems just using the terminal window and even harder with "magic glass". With symbol tags you would easily see where the messages originated. It's a very good idea! Up-vote deserved!

Sorry...... that sparked some ideas.
Tagging and routing by symbols will be a bad idea because the logic decisions need to be taken by 1/0 true/false and so the value needs to head up the list.
But tags could be appended....... to show the route taken.
[route] would always be used instead of [select]...... so that the appended message is preserved...... and then the logical value re"-"placed using [list prepend].
I might start a new thread I think..... to gather ideas and criticism.
A set of specific "normal" and "debugging" objects would be useful, as, for example [myselect 0 1] (which contained values to "send onwards" unlike [sel] ) could be renamed to [myrouter 0 1 router5].
Aarrgh...... probably a huge hole in which to stop digging......
..... and I bet it exists in extended already........?????
P.S.
Is your patch working as you wish?
And reading again.... after all that!..... I think you meant "message or float" and not "symbol or float" to send the zero.
I don't know of any difference, and they send exactly the same data, but the message [1( is more useful for debugging than the float [1] because you can click it and send the message.......
David.
debugger.pd

Thanks for your thoughts...great to get feedback from your very much wider perspective.

RE Bug...bit of a background
It was as you said...but more the point that pd was trying to take exclusive control of the audio i/o and seemed to create a collision...as soon as I unticked the io...it all worked...thanks again.

Your patch seems to work great...good to see a clean up and understand a little deeper.

The help file for input_event still opens so I think the dll is kaput...sadly as there is no other way to undo via midi in Live. Not sure what to do there. Could pd execute an autoit script or dll? That way you could use a direct send to window rather than needing focus?

Im obviously trying to set up performance rig like a hardware box whereby I basically plug up, turn on and play (have performance daw set up on a dedicated surface pro 3 that doesnt do anything else)
I use the setup in a couple of modes;

A. Midi Guitarist
B. Percussionist/atmospheres etc

with LIve as the centre hub.

USB Hardware

1. Floor board is always present (looking for some way of installing better switches on the rig kontrol 3 if anyone has any pointers or maybe arduino/pd/bluetooth would be amazing)
2. UR44 IO always present
3. Fishman Triple Play always present
4. Optional Axiom Controller Keyboard or Percussion controller eg KMI Boppad

In boot sequence (using vbs/autoit script to facilitate auto start up);

1. loopMidi - To setup internal patching
2. Midiox - To take care of different usb hardware being plugged in via vbs as I have had a lot of trouble trying to do this in pd and eventually gave up...although it would be a lot simpler. Can interrogate usb devices plugged in etc
3. Pd patch
4. Ableton Live

So if there are any resources really detailing the auto connection of midi io in Pd, that would be brilliant...would like to remove the need for midiox.

The idea of using arduino to hardwire this into a new foot controller sounds amazing but I just dont have the time to learn more atm...anyone out there interested...Id be willing to donate towards it

@image_engine Bome Midi Translator Classic can send keystroke combinations triggered from midi.
Will it work for windows 10? It almost certainly requires window focus. I have not tried it.
Good that you have your patch working.
I think you will have to keep MidiOx for midi patch reliability. Plug and play (great for non-technical users) has made our lives very difficult using Pd....
There are ways to fix fdti ports for usb, but windows likes to think it knows best for midi.
It might be possible to make a tcl plug-in specifically for your Pd setup. If you open pd/tcl/dialog_midi.tcl and you understand and can edit the contents then you could make a plugin that could re-order and fix ("nail down") the device list.
David.

I did spend a bit of time with Mr Bome (Floria) trying to get timers to work, even writing it all in vbs/midi and then pd. MT is a great tool...
Can pd execute or run any system stuff? The undo isn't millisecond critical...and ideal if I could use autoitx.dll as it doesn't need focus

I'll check out tcl...early morning here...off to play some music

You are a great help David!

@image_engine If you can write a batch file to do what you are looking for....... and widows10 still has a command prompt console...... then you can send a command prompt script like this....... (extended !)...
command_prompt.pd

On my system that opens a new instance of Pd (pd.com)......
but you can replace that message with the content you want to run in the batch file.

However, I don't think you can send keyboard input to another program from a batch file.
You could send a script that opens a vbs script........like....... "C:/path to/myvbsscript.vbs"
Then use SendKeys in the vbs script.
But I think SendKeys has been "removed" from Widows10 recently.

BUT..... you could message to the command prompt (as my example above) to run an autohotkey command....... https://stackoverflow.com/questions/22836457/how-to-make-a-batch-file-to-run-a-hotkey/22843382#22843382 ........ and that should do it.

I cannot help much with widows10. I bought a load of win7 licences for my laptops...... and they are all locked down and update-proof. I learnt a long time ago that a show machine should be re-imaged before every performance, and then kept away from the internet.
If you get it all working in widows10 then make an image of your hard disk with clonezilla and check that it can be restored....... you will need it one day for sure.
David.

That might work...autoitx.dll can target windows directly...might be a bit clunky but Live doesn't have a midi remote for undo...despite their forum being littered with requests.
Totally agree with lock down. My daw hasn't changed since 2011 with xp...no net etc.

See how it goes. Cheers

@whale-av I took a quick look at the tcl file for midi but it just seems to be a form parametisation...Im no guru but couldnt really see anything of substance there.