jayrope Single patches WORK although buggy in patch (maybe PD-related), Button 23 now simply turns the patch off, but doesn't restart them again.

try a simple C++ example

jayrope loop mode then [...] just hangs in blinking LED

Hmmm not sure what LED blinking at what stage, could you clarify ? Also, do you get any log in the IDE when you ope nit up after it "hangs in blinking LED" ?

In IDE: Both C++ and PD work in principal.
However using the button shuts them down, and the patch doesn't restart. I can however restart from the IDE.

    I kind of hate to waste your evening with this. Should we continue this tomorrow? In principal using a Pepper button to shut a patch down does work. Question now would be how restart the same patch, when in single patch mode, or better how to start the next patch in the list, when in loop mode.

    (side note: i somehow forgot how to quote in here)

    EDIT: Idealistically the button would restart the same patch again, when pressed again, or then start the next patch, when in loop mode.

      jayrope However using the button shuts them down, and the patch doesn't restart. I can however restart from the IDE.

      brilliant! And also expected behaviour: when starting a patch in the IDE it is always in single-shot mode: you start it from the IDE and you stop it either from the IDE or with the Button.

      jayrope the button would restart the same patch again, when pressed again

      If a single patch is set to start at boot, pressing the button for less than 2 seconds should do just that: stop the current patch. systemd will then automatically restart it.

      jayrope or then start the next patch, when in loop mode.

      When set to run `loop_*" patches at boot, when one stops the next one will start, so pressing the button should stop the current one - as usual - and then the script should run the next one.

      jayrope (side note: i somehow forgot how to quote in here)

      Select the text and a little "quote" popup should pop up. Make sure you click-drag when selecting because sometimes doing triple click to select a full paragraph doesn't show the popup.

        giuliomoro

        Okay, without IDE single patch mode works.
        -> Button restarts current patch. When pressing more than 2 secs, the board powers down. Bravo!

        Now to the rest of trouble 🙂
        When set to `loop_*" mode it fails to load a patch at boot.
        Using button doesn't load anything either. The rightmost LED above the usb connection to IDE is double blinking
        But it the button does power down the board when pressed for more than 2 secs.

        So i guess there is just one small step missing to make this happen, what could that be?

        When set to loop mode, reboot and then after a while ssh onto the board and run:

        ls /root/Bela/projects
        journalctl -u bela_startup -n 500 | cat

        and paste the contents here please

        Here it is (example TempProject doesn't show up in my list of projects in IDE)

        root@bela:~# ls /root/Bela/projects
        2_osc_harm_ring 2_osc_ringed e340 pd-externals
        2_osc_harm_ring_3 2_osc_ringed_distorted_or exampleTempProject
        root@bela:~# journalctl -u bela_startup -n 500 | cat
        -- Logs begin at Thu 2016-11-03 17:16:43 UTC, end at Thu 2021-09-09 08:17:17 UTC. --
        Nov 03 17:16:51 bela systemd[1]: Started Run Bela at boot.
        Nov 03 17:16:51 bela systemd[1]: bela_startup.service: Main process exited, code=exited, status=2/INVALIDARGUMENT
        Nov 03 17:16:51 bela systemd[1]: bela_startup.service: Unit entered failed state.
        Nov 03 17:16:51 bela systemd[1]: bela_startup.service: Failed with result 'exit-code'.
        Nov 03 17:16:51 bela systemd[1]: bela_startup.service: Service hold-off time over, scheduling restart.
        Nov 03 17:16:51 bela systemd[1]: Stopped Run Bela at boot.
        Nov 03 17:16:51 bela systemd[1]: Started Run Bela at boot.
        Nov 03 17:16:52 bela systemd[1]: bela_startup.service: Main process exited, code=exited, status=2/INVALIDARGUMENT
        Nov 03 17:16:52 bela systemd[1]: bela_startup.service: Unit entered failed state.
        Nov 03 17:16:52 bela systemd[1]: bela_startup.service: Failed with result 'exit-code'.
        Nov 03 17:16:52 bela systemd[1]: bela_startup.service: Service hold-off time over, scheduling restart.
        Nov 03 17:16:52 bela systemd[1]: Stopped Run Bela at boot.
        Nov 03 17:16:52 bela systemd[1]: Started Run Bela at boot.
        Nov 03 17:16:52 bela systemd[1]: bela_startup.service: Main process exited, code=exited, status=2/INVALIDARGUMENT
        Nov 03 17:16:52 bela systemd[1]: bela_startup.service: Unit entered failed state.
        Nov 03 17:16:52 bela systemd[1]: bela_startup.service: Failed with result 'exit-code'.
        Nov 03 17:16:52 bela systemd[1]: bela_startup.service: Service hold-off time over, scheduling restart.
        Nov 03 17:16:52 bela systemd[1]: Stopped Run Bela at boot.
        Nov 03 17:16:52 bela systemd[1]: Started Run Bela at boot.
        Nov 03 17:16:52 bela systemd[1]: bela_startup.service: Main process exited, code=exited, status=2/INVALIDARGUMENT
        Nov 03 17:16:53 bela systemd[1]: bela_startup.service: Unit entered failed state.
        Nov 03 17:16:53 bela systemd[1]: bela_startup.service: Failed with result 'exit-code'.
        Nov 03 17:16:53 bela systemd[1]: bela_startup.service: Service hold-off time over, scheduling restart.
        Nov 03 17:16:53 bela systemd[1]: Stopped Run Bela at boot.
        Nov 03 17:16:53 bela systemd[1]: Started Run Bela at boot.
        Nov 03 17:16:53 bela systemd[1]: bela_startup.service: Main process exited, code=exited, status=2/INVALIDARGUMENT
        Nov 03 17:16:53 bela systemd[1]: bela_startup.service: Unit entered failed state.
        Nov 03 17:16:53 bela systemd[1]: bela_startup.service: Failed with result 'exit-code'.
        Nov 03 17:16:53 bela systemd[1]: bela_startup.service: Service hold-off time over, scheduling restart.
        Nov 03 17:16:53 bela systemd[1]: Stopped Run Bela at boot.
        Nov 03 17:16:53 bela systemd[1]: bela_startup.service: Start request repeated too quickly.
        Nov 03 17:16:53 bela systemd[1]: Failed to start Run Bela at boot.
        Nov 03 17:16:53 bela systemd[1]: bela_startup.service: Unit entered failed state.
        Nov 03 17:16:53 bela systemd[1]: bela_startup.service: Failed with result 'exit-code'.

        Obviously there is the failed state block repeating several times.

        right, easy fix: for •loop_*• to work, you need projects whose name starts with loop_. For instance if you want to run 2_osc_harm_ring, 2_osc_ringed and 2_osc_harm_ring_3 in a loop, you have to save them as
        loop_2_osc_harm_ring, loop_2_osc_ringed and loop_2_osc_harm_ring_3.

        (EDITED for clarity/typos)

        It needed a few reboots & now it works. Bravo!
        Using mv the_file loop_the_file created an extra ressource file under the old name in it's project folder, which was confusing Bela.
        Maybe a missing flag missing ... I deleted those ressource files, and all works after reboot.

        This feature makes a BIG difference for me for live use. I am very grateful for your support in this!

        Refining the new state:
        To prevent accidental firing in live use i'd propose for the button to only fire "next patch",
        when it has been pressed for at least 1 second.
        If so, then change the timing for the power down function to say 5 seconds.
        This could also be achieved, if the button would only fire "next patch" OR "power down", when a second button is pressed at the same time, behaving like a shift button.

        And question:
        IF the above would work -> could one reactivate the now redefined "next patch" button to be used in PD or elsewhere for tap buttons, triggers and other short pressed uses (that possible at all?)?

        Thank you for all you do!

          jayrope Apparently using mv the_file loop_the_file created an extra ressource file under the old name it's project folder, which was confusing Bela.

          how was it confusing it? Was it throwing an error of sorts? That file is actually always there, it is the binary that gets built and run, but it is normally hidden in the IDE. If you do "save as" from the IDE it will delete it for you.

          jayrope As a good precaution for accidental firing in live use i would propose for the button to only fire "next patch", when it has been pressed for at least 1 second

          good point. This requires another change in core/PRU.cpp: find the lines

                          if(++stopButtonCount > 10){
                              printf("Button pressed, quitting\n");
                              Bela_requestStop();
                          }

          just below your previous edit. You can then replace 10 with something like context->audioSampleRate / context->audioFrames * 1.0, where 1.0 is the number of seconds you want to wait before the button stops the current patch.

          and then additionally give the power down function a bigger delay of say 5 seconds

          to do this you need an extra parameter to bela-cape-btn in the bela_button.service file: --hold-press-timeout-ms 5000

          jayrope And question: IF the above would work could on reactivate the now redefined "next patch" to be used in PD or elsewhere for tap buttons, triggers and other short pressed uses (that possible at all?)?

          I think it should work.

          jayrope This could also be achieved for the button to only fire "next patch" OR "power down", when a second button is pressed at the same time, behaving like a shift button.

          This is more complicated, I was thinking that maybe what I need to add is a way for the Pd user to stop the program by sending a Pd message. Then it is up to your Pd patch to handle the logic for triggering that message (this can coexist with the other methods). All that should be needed to achieve this is adding this patch to core/default_libpd_render.cpp (untested):

          diff --git a/core/default_libpd_render.cpp b/core/default_libpd_render.cpp
          index bcec769c..443726cf 100644
          --- a/core/default_libpd_render.cpp
          +++ b/core/default_libpd_render.cpp
          @@ -350,6 +350,11 @@ void Bela_listHook(const char *source, int argc, t_atom *argv)
           #endif // BELA_LIBPD_GUI
           }
           void Bela_messageHook(const char *source, const char *symbol, int argc, t_atom *argv){
          +       if(strcmp(source, "bela_stop") == 0)
          +       {
          +               Bela_requestStop();
          +               return;
          +       }
                  if(strcmp(source, "bela_setMidi") == 0)
                  {
                          if(0 == strcmp("verbose", symbol))

            giuliomoro jayrope Apparently using mv the_file loop_the_file created an extra ressource file under the old name it's project folder, which was confusing Bela.

            how was it confusing it? Was it throwing an error of sorts? That file is actually always there, it is the binary that gets built and run, but it is normally hidden in the IDE. If you do "save as" from the IDE it will delete it for you.

            I used mv, because i see no patch rename function in the IDE. Probably overlooked it.
            When the ressource files were visible, Bela simply hung during boot, there was a loop of two processes going on, but the log has been deleted already...
            anyhow deleting the visible ressource files from the project folders has solved this.

            Now trying your suggestions to change button timing, guessing though, that if(++stopButtonCount > 10){
            printf("Button pressed, quitting\n");
            Bela_requestStop();

            just needs a higher number than 10?
            }

              jayrope I used mv, because i see no patch rename function in the IDE. Probably overlooked it.

              there is no one as such - unfortunately - but there is a "save as".

              jayrope When the ressource files were visible, Bela simply hung during boot, there was a loop of two processes going on, but the log has been deleted already...

              weird one

              jayrope just needs a higher number than 10?

              This count is in blocks, so changing the blocksize will affect the number of blocks per second, so waiting 1000 blocks will take different amounts of time depending on blocksize. The way I suggested it you can enter the actual number of seconds you are interested in and it will be always the same time regardless of blocksize.

              Activating button after 1 sec works, thank you.
              I suppose i make a mistake regarding the timeout for shut down, my bela_button.service file looks like this

              Description=Monitor the Bela cape button
              After=networking-online.target
               
              [Service]
              Type=simple
              ExecStart=/usr/bin/stdbuf -oL -eL /usr/local/bin/bela-cape-btn --pressed 1 --pin 86 --hold /opt/Bela/bela_button_hold.sh --delay 20 --monitor-click 0
              Environment=HOME=/root
              --hold-press-timeout-ms 4000
               
              [Install]
              WantedBy=default.target

              what am i doing wrong?

              The --hold-press... part shouldn't be on a line of its own, it should be at the end of the line with bela-cape-btn

              So this should be right?

              [Service]
              Type=simple
              ExecStart=/usr/bin/stdbuf -oL -eL /usr/local/bin/bela-cape-btn --pressed 1 --pin 86 --hold-press-timeout-ms 4000 --hold /opt/Bela/bela_button_hold.sh --delay$
              Environment=HOME=/root

              you have --delay$ which should be --delay 20 --monitor-click 0
              In other words, the line should be:

              ExecStart=/usr/bin/stdbuf -oL -eL /usr/local/bin/bela-cape-btn --pressed 1 --pin 86 --hold-press-timeout-ms 4000 --hold /opt/Bela/bela_button_hold.sh --delay 20 --monitor-click 0 

                giuliomoro The --delay$ was a copy error from my Terminal (OSX). It's been a few hours of back & forth, with things like pressing button for 1 sec, resulting in patch change ... but then an immediate shut down as well, although i surely hadn't pressed 4 secs for shutdown. There's been other weird things that i'll spare you from.
                Trying between standalone and IDE or just SSH connected modes also produce different results occasionally.

                Now it functions in standalone, but not the shutdown command. For me that's good, as i wouldn't need shutdown probably. Just trying to make sure my rack is fucntional for a concert on Saturday.

                Thank you again, and for now, this week I'll create no more troubles 🙂 Enjoy the weekend.

                a month later
                a year later

                OMG I fixed it. The SD card was falling out on the back! Due I think to hitting the USB cable upon installation to the rack - Whew!