tempvar[0] = {random(0,1),random(1,2)}
debug.print tempvar
' or even debugPrint(tempvar)
That was my original idea but a dedicated routine (like debugPrint) would help to specify the variable to be saved.
Khm… Actually yes. What about an extension screen on the left? Something like this:
I didn’t think of this one but looks like a good idea. Like the clipboard is updated if the cursor is above the module.
(Otherwise a routine like debugPrint() in one of the BASICally modules could create problems working with Ctrl-C and Ctrl-P in other modules.)
(I see Bruce’s post about the portable sequence protocol but I don’t think it would be feasible in case of BASICally.)
Nope.
Yes. Like “dump.txt”, or “debug.txt” in one of the standard folders.
I don’t think so.
… just once again: I realize that this isn’t the most important thing. Don’t waste much time on this idea if it seems to be problematic.
Your unutilized programming skills will always find something essentially useful. (Like customizable font size? )
Didn’t Andrew say explicitly that he would be willing for someone to adopt prototype for v2 because demand (low) vs technical complexity (high) meant he didn’t think it was feasible for his business to support?
He did start a v2 branch but I think it needs an owner
I know he said that somewhere which wasn’t a dm : email but I can’t find it.
I also vaguely recall something like that. But I also vaguely recall him saying something after that to the effect of him wanting to break out the different supported languages into different modules. Whether he means to do it I don’t know. Sorry, too lazy to search right now
I have been having fun with BASICally in various forms, but mostly as parameter remapping/translation between two modules. I was starting to do some scale translations but to do that chromatically would require 12 inputs or 12 channels. Is there a reason that you did not support 16 channel polyphony on IN1? I could probably kludge up a 2 BASICally instance script where the first takes a poly external scale and sends serially as value and index on two BASICally inputs, but that would being quite a kludge.
Have you done or seen anyone do something like this that requires more than 9 channels? Thanks.
Before I get to polyphony, why does note translation require an IN/OUT for each note? That’s what you’re implying with the connection between chromatic scale and the number 12.
In the built-in presets for BASICally, there are some different kinds of quantitizers available. I suspect you could change the values in one of them to get the effect you want.
But IN/OUT are about signals, not individual notes. Unless you are using a source that puts each note on a different wire? Is that a thing?
I am working with diatonic scales of 7 notes from a chromatic scale of 12 semitones. So, the scale is data or signals. Sometimes I have 5 note pentatonic scales. “Poly External Scale” uses 12 channels.
I can and have kludged things together to do what I want to do, but, it would be a lot simpler with polyphony. But, I understand that you may not want polyphony in BASICally for some reason.
I am using BASICally as a mapping or translation layer wherever I might find a use for such. Most things work fine with the current mono inputs and outputs. Occasionally it would work better to be able to send in an array via polyphony.
Ah, I see. The “12” is the number of channels in that output from your module.
The reasons I haven’t thought a lot about supporting polyphony are:
Seems really unlikely that I can use the rack:simd library to do these computations, so it’ll greatly increase the CPU consumed. But maybe that is constrained by knowing the number of channels present.
Not sure how to change the language to support it. No way that I love has come to mind yet.
The use case suggestion you seem to be making, which I find interesting, is:
Do the same computation on every channel in IN1, and then apply that to the corresponding channel in OUT1.
That perhaps suggests a new construct, like (spitballing here):
FOR IN1 TO OUT1
foo = in1 + 1 ' Something simple.
IF foo > 3 THEN
out1 = foo - 3
ELSE
out1 = foo
END IF
NEXT
When BASICally is running this loop, it iterates through all of the channels in IN1, and within the confines of the loop, "in1’ refers to the particular channel value.
This could get needlessly slow in your case if, for example, there’s a FOR loop used to compute the corresponding out1 (like I have in the quantizer presets), for two reasons:
It doesn’t really need to run this every cycle; most cycles, the IN1 and OUT1’s will be the same.
FOR loops have a built-in “WAIT 0” in the NEXT, so that FOR loops don’t exceed the cycle’s time budget too easily.
So, stuff to chew on here. But am I understanding the use case better?
I think of BASICally as more than a signal handler. So, I think of it as general purpose computing. I have not used SIMD, so I am not familiar with the limitations.of this vectorization.
In a general case, IN1 channels are independent of OUT1 channels. I want to supply BASICALLY with an array of 12 “poly external scale” values where the values can be 0.0, 8.0 or 10.8 and for a diatonic scale, only 7 slots will non-zero values or 5 for a pentatonic scale. Then I would want to output a 7 or 5 member array. Right off the bat, I do not see how this would work
I should probably stick with using BASICally as it is as it would probably be very difficult to have a general purpose approach to polyphonic input and output. Of course BASICally can dynamically set the channel count for any output port, as Meander does for chord and bass, but, it might not know this at first and the language would have to support dynamic polyphony.
Thanks for considering this though. If I am able to do what I want with the existing version, I will let you know…
What about an extension screen on the left? Something like this:
)