NGR feature request: Simple loop construct

[Duggle]

My usecase is to play a phrase in a loop continuously while designing synth patches.

The simplest way I can think of is a label-goto pair.

Something like this would be fine:

if ^section == 10
loop10:
  if BUTTON:8 > 0
    #loop phrase until button toggled
    send NoteOn USB1 1 24 100
    delay_ms 1000
    send NoteOn USB1 1 24 0
    goto loop10
  else
   exit
  endif
endif

 

Of course  a more sophisticated (and structured) 

while {expression}

..

wend 

would be welcome also, or instead of goto!

[TK.]

I already spent some thoughts on this, but it still needs some conceptional work.

 

E.g. there must be a way to terminate the loop from external (at least from the MIOS terminal) in case of a programming error (endless loop), otherwise the danger is too high that it won't be possible to update the .NGR file via MIOS Filebrowser without unwanted side effects (e.g. application crash).

This is especially required for the case that the loop already starts in the DEFAULT.NGR file... etc...

 

Another potential issue is, that somebody could think, that a time consuming loop would run without side effects.

But currently we would have such effects, e.g. LCD output triggered by events won't be handled as long as the .NGR script is executed.

 

Allowing more "multitasking" will require a lot of extensions, which I actually wanted to omit.

 

And btw.: I'm also pretty sure that the next request will be to allow some "simple" calculations, and variables, etc... things which will cause more effort at my side than initially planned.

 

Best Regards, Thorsten.

[Duggle]

Yes, I think I understand some of the potential for problematic side effects, complexities etc.

 

Without adding anything to the NGR capability a couple of methods come to mind:

• Using (very?) long sections that poll the button/control state regularly to exit
• Could there be a way of re-triggering the execution of a meta by another/or same control thus repeating a section but without the linguistic complexities?

[TK.]

Using (very?) long sections that poll the button/control state regularly to exit

 

yes, you can already do this

 

 

 

Could there be a way of re-triggering the execution of a meta by another/or same control thus repeating a section but without the linguistic complexities?

 

yes, this is already possible:

exec_meta RunSection:<section>
exit

 

 

As you can see, you are even able to start the .NCR script with different ^section values to execute different branches.

 

Btw.: meanwhile I got an idea how to deal with delays and SD Card access (just close the file, release the mutex, wait for x mS, take back the mutex, re-open the file).

In addition, a new Meta event makes sense which allows to terminate the execution (resp. clear an open request).

I will try this tomorrow.

But my statement is still true, that I don't plan to add language extensions to control the program flow.

 

Best Regards, Thorsten.

[Duggle]

What I think I'd like to do is have a button that triggers the execution of a section which I've done following the provided example:

# start script with ^section == 1
EVENT_BUTTON id=1  type=Meta  meta=RunSection:1  button_mode=OnOnly

 

I'm just not sure what to put (and where) to make the section re-trigger on completion as long as the toggle mode button is in the active state?

[TK.]

This is not a toggle mode button, you would have to specify button_mode=Toggle instead.

 

Then you can write (I haven't tried it out, but I hope that you get the idea how it could work):

 

if ^section == 0
  exit
endif

if ^section == 1
  log "Section 1 called"
  # do this
  # and that
  # maybe with some delays:
  delay_ms 1000
  # and finally:
  if BUTTON:1 != 0
    log "Retriggering section 1"
    exec_meta RunSection:1
  else
    log "Finished."
  endif
  exit
endif

 

 

Hope that it works (last mail today... ;-))

 

Best Regards, Thorsten.

[Duggle]

Functionally it works, fantastic! :frantics:

 

For reference here's the section:

if ^section == 4
  send NoteOn USB1 1 36 80
  delay_ms 500
  send NoteOn USB1 1 36 0
  send NoteOn USB1 1 38 80
  delay_ms 500
  send NoteOn USB1 1 38 0
  send NoteOn USB1 1 40 80
  delay_ms 500
  send NoteOn USB1 1 40 0

  if BUTTON:3 != 0
    log "Retriggering section 4"
    exec_meta RunSection:4
  else
    log "Finished."
  endif
  exit
endif

 

and here's the terminal output (missing endif message, repeats the else branch twice):

[1045.724] Retriggering section 4
[1045.725] [MBNG_FILE_R:56] WARNING: missing ENDIF command!
[1047.230] Retriggering section 4
[1047.231] [MBNG_FILE_R:56] WARNING: missing ENDIF command!
[1048.737] Finished.
[1048.738] [MBNG_FILE_R:56] WARNING: missing ENDIF command!
[1050.243] Finished.
[1050.245] [MBNG_FILE_R:56] WARNING: missing ENDIF command!

Neither of these is a problem because the midi is generated perfectly.

 

[Duggle]

Btw.: meanwhile I got an idea how to deal with delays and SD Card access (just close the file, release the mutex, wait for x mS, take back the mutex, re-open the file).

I think this could be very helpful, as I've found the controls to be very slow to respond while a phrase is playing.

[TK.]

The wrong warning message is fixed, and the "delay_ms" command has been improved, so that it doesn't stall SD Card accesses anymore.

This means, that you can now use the filebrowser without conflicts while the .NGR script is executed.

 

The new "RunStop" meta event has been added, which allows to stop the execution of a script with a control element (e.g. button)

And a "runstop" terminal command is available as well - just for the case...

 

Best Regards, Thorsten.