Using the example for recording samples while holding a button, is there a proper way to do the same thing with writesf~? Because writefs~ seems to fire the the stop at the same time as the start, so the button is cancelled after the 2s delay:

I assumed I could follow the same concept as the tabwrite~ example:

Perhaps buttons need a check to confirm it’s still being held before sending any 0? Is there a different approach to take when using writesf?

Based on: https://forum.bela.io/d/3642-loading-new-audio-files-every-30-seconds/12

Can't test, currently away from any Bela. But perhaps a [change] would fix the issue?
If the values coming from the buton via [r bela_digitalIn18] contain a stream of ones, you will send multiple subsequent start messages to tabwerite~.

    max i;m not sure where you would put a change that would solve the button from sending 0101010 when pressed, or at least more than one state change per press

    is there a good pd button method?

      And if i fake a button press myself locally, the recording doesn't go past the delay? so no matter how long the button is pressed, the audio recording is 1 second, same as the delay to stop

        When I push a button [select 1 0] fires two 0's and one 1, so i'm assuming that the delay is triggered at the same time as the button and thus only 1 second between start/stop

        Are you still having that issue with the digital in flooding you with 0101010101 messages? No amount of Pd will fix that, as it's probably a lower level issue.

        [r bela_digitalIn18] gives you a float. This float going into [delay] sets the delay time to 0 or 1 and starts the delay, so there is effectively minimal or no debouncing at all. There is a mistake in the patch you are using as a reference. This debouncer is designed for getting rid of mechanical bounces of the contacts in your switch, which typically are 3 to 8 ms long, so a [delay 8 ] should do.

        I am not sure about the "60 permin" syntax of the other delay and I don't have the helpfile at hand, but I would just make it 2000 (default: millisecond) .

          button-hold-recording.pd
          4kB

          I'm just going to upload my .pd incase i'm doing something stupid. as it stands, holding the button creates a cluster of audio files before you've even left go of the button.

          I assume, as above, i need some sort of 'double check you're not sending 1 1 1 1 1 1 and tricking the increment to go up

            eyeversuseye incase i'm doing something stupid.

            I tried to say above that you should not send a float into [delay 8], but a bang, if you want it to work as a debouncer. E.g.:

            With this change, the patch looks good to me.

            giuliomoro Are you still having that issue with the digital in flooding you with 0101010101 messages?

            Is this still the case? If it is, then this is the reason you are experiencing "the button creates a cluster of audio files before you've even left go of the button."

            eyeversuseye And if i fake a button press myself locally, the recording doesn't go past the delay? so no matter how long the button is pressed, the audio recording is 1 second, same as the delay to stop

            I don't see why that would be the case, maybe something wrong with how you are fake pressing it ? Try the modified patch below, it contains a toggle to emulate the button press on your computer. Set the toggle to emulate the button being pressed, clear the goggle to emulate the button being released.

            button-hold-recording.pd
            4kB

                  I retract my last comment, i didn't re-run the patch.

                  I think this is now working as it should be, I just have to figure out if the button is pressed again within that 2 second delay, the filename gets incremented before the recording stops and an empty file is created.

                  but for the button pressing, it seems to be happier about the situation

                  re: for my 'fake' button on the bela, i was just putting jumper between 27/18

                    eyeversuseye I mean, the answer of course is to send a stop as soon as the button is released, not delay it by two seconds