Howdy...have not been here for quite a while but was trying to finish some of the work I had done previously...I noted when I boot up the pd script, the first time I send a note message to the attached patch, the note on event ie 127 vel does not trigger the timer. When the first pedal up is released, the timer is actually showing the time from the start of the program to the time up. When I press the pedal down and up again ie send noteon/off all is working as it should...any ideas? Any help greatly appreciated.

The idea is that fast taps ie on/off send tap values to Live...a long hold down waits for the note off the send a stop message.

This script is connected to note in...looking for note 125 on ch13

Tap Tempo.pd

Hi,

Maybe I am missing something, but the timer in this patch seems to work well. I tried sending messages with values 0 and 127 to it (after sending a 125 to open the [spigot], of course), and the timer shows no problems here. It shows to me the time elapsed since the first 127 value arrived and not the time since the patch was loaded. Can you please explain better what issue you are having?

Also, some comments on your patch:

• using [expr if($f1 > 1250, 1, 0)] is a bit of an overkill since it is identical to [> 1250], and also using [expr if($f1 == 125, 125, 0)] to open the spigot is identical to using [expr if($f1 == 125, 1, 0)] (since the spigot opens whenever the value in the right inlet is different than 0) which in turn is identical to [== 125]

• I personally would use a [pack f f] above the [stripnote] and send the note number + velocity as a single list to it, since when using the right inlet you must make sure that the velocity arrives always first and this can be easily forgotten in a more complex patch

Cheers,
Gilberto

Thanks for all your help Gilberto;
Great to know the optimisations. Im used to a lot of other scripting which is not quite so terse...
In theory it should work but in real time, I have a copy of the patch used elsewhere and it also shows a bug where I change the note number to eg 91 and it still lets through the 127 on the first note change which of course starts the time until I click 125 again which false triggers as the time is >1250
The note number 125 should be exclusive and no vel should even make it past the spigot so it would seem a timing issue.
Cheers

@image_engine Would you be able to provide a sample patch which uses your abstraction and which displays the issues you describe? Because the problem could be related to the hardware side of things (and then it would be difficult to diagnose, except to say that the abstraction works as expected) or it could be in the patch which uses the abstraction. As an example, it could be that the abstraction works well but the order that the information arrives at it from the main patch could be wrong.

Cheers!
Gilberto

@gsagostinho Here is a standalone module with the patching updated as per your suggestions. I am sending a note number 125 on/off then a nn 91 and the first send of 91 still triggers the note on bang but the note off is ignored...then sending 125 again, the note on is ignored...hope that makes it a bit clearer.
Tap Tempo SA.pd

EDIT: Actually your comments about expr made things a lot clearer...it was a timing issue and sorted by simplifying in this example...welcome your comments
Tap Tempo SA 02.pd

Actually your comments about expr made things a lot clearer...it was a timing issue and sorted by simplifying in this example...welcome your comments

I am glad to hear that!

If you don't mind, I have just two comments about yout "Tap Tempo SA 02.pd" patch which might help you in the future, even though you said everything is working now:

• you are using [expr] for something that could be done with a single maths objects since [expr $f1 > 1250] is the same as [> 1250],
• I would highly recommend you to use [trigger] objects (or the shorthand [t]) when having two patch cords coming from a single object and in which their order matters. Pd will always send data first through the cord which was created first, and this can get messy and can lead to hours of debugging. In your patch, I would add a trigger below the bang button which feeds both the [timer] and the [f] objects, to ensure that the timer gets banged first than the float.

Cheers!
Gilberto