and when you start the program from the IDE it should show that it rebuilds PRU.cpp, is that the case?
Pepper: restart/reset/*loop* button
Okay IDE is single patch mode is doing something
Building PRU.cpp...
...done
Linking...
...done
Enabling Bela at startup in a loop...
project set to run on boot succesfully
Running several different patches then each say
Button pressed, quitting
...done
Enabling Bela at startup in a loop...
Bela stopped
project set to run on boot succesfully
All in IDE.
- Edited
giuliomoro No, none of the projects run (all PD). Upon running them they load and then quit saying
Button pressed, quitting
Bela stopped
EDIT: This also goes for the PD patches in the examples
ok, what is the content of /root/.bela/belaconfig at the moment?
- Edited
Also i have removed PRU.o again (rm /root/Bela/build/core/PRU.o) to force rebuild PRU.cpp, the rebuild happens, but at last
Button pressed, quitting
Bela stopped
appear again
ok, what is the content of /root/.bela/belaconfig at the moment?
- Edited
My bad. It was empty !!!"§$%&/&%$§
now has "CL=--stop-button-pin 86 " in it, trying IDE again [...]
Single patches WORK although buggy in patch (maybe PD-related), Button 23 now simply turns the patch off, but doesn't restart them again.
So that's equivalent to a Bela shutdown i guess, BBB stays on.loop mode then [...] just hangs in blinking LED ... after restart loop mode plays only from IDE, then shuts down Bela and BBB upon button 23 press. After two restarts loop plays last chosen in IDE then shutsdown everything with button.
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.
- Edited
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 | catand paste the contents here please
- Edited
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
(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?
}
- Edited
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.