BASICally: a new module for writing code within Rack

How could you have a priority inversion? Do you have the audio thread acquire a lock? That is of course strictly “forbidden”. Looking at the code quickly the only lock I see is in the GMOCK test stuff.

My concern is that I’m doing an unknown amount of work during compilation. And the version in development does some allocations with “new”, which I understood to be a source of priority inversion. Am I mistaken? Malloc was mentioned as not having bounded time, is the same not true for ‘new’?

oh, no, you are correct - every implementation of new I’ve seen calls malloc, and ends up locking a mutex. So, yeah, you are not supposed to call malloc/new ever on the audio thread. You can either ignore the problem, or do all the allocations on some other thread. The latter is what I do when I need/want to malloc/new in the audio processing code.

@k-chaffin, @Andre_M, and anyone who has opinions, I have an early-beta version I’d like you to try.

I’ve been working on some functionality I’ve been calling “multithreading”, for lack of a better term. It allows the user to create multiple “blocks” of code that can run in parallel.

It’s working, so far as I can tell, though I suspect some cases haven’t been tested. but I’d love some pre-release confirmation that the design is reasonable and not terribly confusing. Or more likely, I’d like to hear where the design needlessly prevents useful functionality and how I could improve it; or, you know, that it outright doesn’t work.

The builds are here. The docs have been updated a bit, but I’d take suggestions on what needs to be sharper.

Briefly, this introduces two new functions, start() and trigger(), two new commands, CLEAR ALL and RESET, and some new structures that are the meat of the this change.

To make you want to look at the docs, here’s a few examples:

' Two beats, one making 40 pulses per second, one making 2.
' Note that they do drift out of phase because there are 40 NEXT/second
' vs two NEXT/second, and those cost the first loop 40/sample_rate()ths of a second
' every second.
' Not sure how to address this.
for i = 0 to 39
  out1 = 2
  wait 10
  out1 = 0
  wait 15 - 1000 / sample_rate()
next

also
for i = 0 to 1
  out2 = -2
  wait 10
  out2 = 0
  wait 490 - 1000 / sample_rate()
next
end also
WHEN START()
a[0] = { -1, 3, -3, 1, 2, -2, 5, -4 }
for b = 0 to 7
  c[b] = sin(a[b])
next
END WHEN

ALSO
for loop = 0 to 7
  out1 = a[loop] 
  out2 = c[loop]
  wait 1
next
END ALSO
' A trigger to IN9 resets the speed the notes are played.
FOR n = 0 TO 3
  out1 = note[n]
  WAIT pause_length
NEXT

WHEN start() or trigger(in9)
note[0] = { c3, g3, c4, c4 }  ' The notes in my score.
pause_length = random(100, 1000)  '  How fast we play the notes.
RESET  ' Force main block to restart now
END WHEN

@k-chaffin, what you’ve been asking for is now:

WHEN trigger(in9)
  RESET
END WHEN

Love to hear what you all think.

Mahlen

1 Like

I downloaded and installed V2.0.5 . I will try to take a look at it tomorrow. I’m pretty involved in something else, so I am not sure how much time I will spend on it.

Just looking at what you wrote above, I like the triggered reset.

Is the new build V2.0.5? Just trying to tell if the download worked.

Oh, uh, yeah, I haven’t updated the version number in the config before doing that build. For clarity, I’ve now done that, and put 2.0.6 builds here.

No hurry, BTW. While fixing the priority inversion on compilation, I realized that the Bison+Flex compiler isn’t reentrant* , and I expect that might take some time to fix.

  • When I load a patch with six BASICally instances in it, only a couple of them will compile correctly.

I am a bit stupid, I don’t know how to download the plugin from there, haha. Maybe I should have an account on github to download stuff… Can you drop it on google drive?

1 Like

Ah, good to know on the version. I was able to see the additional ports so figured I had the correct version.

I’m going to try out using BASICally in my current drum machine patching efforts so I can look into it more deeply while making progress on my drum patches using Ohmer QuadPercs and my drum patterns from Meander for Windows from 25-36 years ago.

For some reason, when I install from this location for Windows, I still get 2.0.5 .

If this shows “Fix”, does that mean that I still do not have the 2.0.6 version?

BTW, I deleted your plugin from my plugins folder before I downloaded and installed the V2.0.6 Window build that you linked to. I did this before the START() test above.

I just noticed that now the Fix message is highlighting the a[0] = {} line:

did you use a carriage return in the middle of the array contents or is the module doing word wrapping?

I just copied and pasted from Mahlen’s examples above. Maybe that is not allowed? I bet it has to do with the current module width. Just increasing module width did not fix it. Re-pasting the code now has me back to the Fix message on WHEN START() .

oh ok, not able to use VCV until later so wondered if the syntax validator had a problem with a carriage return in the middle of a line.

I just now typed in the WHEN START() snippet and I get the same error. Since the module version still shows to be 2.0.5 and the START() instruction is not recognized, I suspect I still do not have the right version of the plugin.

Confirmed, you need to log in to github to download. Thats not much to ask - the github login is free of charge.

anyway, here’s a link (expires in 30 days) https://hidrive.ionos.com/share/sshxk2p9tg

2 Likes

Just for the fun of it, I installed your build for Windows but I still have the “Fix” errors with the example scripts and the version still shows to be V2.0.5 .

Thank you!

Yeah, it’s not much to ask, but I forget my passwords all the time (even if i write them somewhere, I just forget where it was), so I am trying to live as password-free as possible…

i just wiped the plugin dir from my \rack2\plugins folder and installed from the Win.zip

I don’t know where you read the version number, but mine seems ok.

1 Like