āā
Absent any actual information on motivations, I can imagine a few reasons:
- This paragraph in the docs gave me pause: āWhen opening a patch containing a VCV Prototype script, a security warning is displayed before it runs. Only load scripts from patch artists you trust. *Running Prototype scripts from untrusted sources may compromise your computer and personal information.ā Yeah, running any random schmoeās code is a vast security hole. No amount of, āwell, you clicked OKā would untarnish VCVās reputation as āVCV hacked my laptop!ā
- Similarly, I would think that fatal bugs in client code (like divide by zero) would be impossible to protect against. āVCV crashes randomlyā is another reputation hit you donāt want. Admittedly, this can happen with modules too, but that code is to some extent reviewed by VCV, I believe.
- Even less serious bugs stop Prototypeās process engine, implying āVCV canāt be used onstage, it will stop making the right sounds.ā While creating BASICally, I realized that halting runtime errors had to be eliminated from the language, even though it makes the language be pretty odd.
- While I love being catered to, I suspect the audience for Prototype was, eh, not huge?
Again, this is just me speculating from afar.
Not used āprototypeā,but seriously,good idea module
Lua jit,VUlt,Faust,Super Collider
Iām going to bet your are wrong on this. Shall we say $5?
Well, @Squinky, youāre far closer to the source of these decisions than I am, so Iād imagine you are far more knowledgeable than I on this point. So while I love wagering on beliefs, Iām not convinced this is an equal knowledge bet. I would not be at all surprised to be mistaken. Note my business card from my previous job:
Also, given that this question has been raised a few times with no answer from the Rack gods, Iām also concerned that itāll never be answered, so the wager would remain in limbo, unsatisfyingly.
If you have theories as to why Prototype has never been ported to 2.0, Iām all ears. Alternatively, if you can get an answer as to why, that would even more interesting. I can certainly imagine other reasons myself!
oh, I got no idea - I just didnāt think those theories sounded plausible. Anyway, I have no āinside infoā on this
fwiw, last time I remember having a business card I think I was āpart of the magicā
Seriously,āStocā,add āfunctionāā¦
Decomposing a code with functions is the minimal habit now
Easierā¦more logic
āReferenceā could also be very very nice
Iāhave used AUTO ITā¦Very nice dialect
Blitz3Dā¦Niceā¦
The āreference manualā of this 2 dialects are top notch
100% perfect syntax files.
RJtexted is a really good āIDEā?
And the Blitz3D portable compiler wrapperā¦Written in AutoItā¦2 ways for STD_OUT
And the source
I donāt want to go on specifics forum,so maybe with random,files will be shared
@ StochasticTelegraph , Is there a way to save/memorize the variables? Or are you considering an āExport variables to TXTā feature in the context menu in version 2.2.99?
Use case: letās say I have a pretty CV pattern generated by BASICally and Iād like to use that one again. (See example below.) Ctrl-C doesnāt help so currently I send the CV to another module and record it there.
' this is the pattern creation
if in9>2 or start() then
for i=0 to 255
volt1[i]=random(0,10)
next
pos=-1
end if
' calculating the next step
pos=pos+1
' sending out the first eight of the voltages
out1=volt1[mod(pos,8)]
I have thought a bunch about āsaving variablesā, so itās interesting to hear your confirm its utility.
Q: are you trying to save the pattern for use later in the playing of this patch, or do you want it to be available the next time you start the patch? In other words, does the data need to survive patch restarts?
Q: Is the data small (series of CV) or large (10 second audio sample)?
Q: once itās saved somewhere, for some length of time, how do you want to refer to it? We typically refer to files by string names; I wouldnāt mind avoiding adding strings to the language, but are strings the obvious choice here? If you were, say, saving CV sequences for automatic playback later, then maybe string names arenāt helpful?
Thoughts?
Naming things is incredibly important for conveying what the thing is. Especially important when you set something aside for a while and come back later. So, Iād say āstringsā (i.e. names) are important.
I remember when some implementations BASIC allowed only one or two-letter variable names, which made it much harder to understand a program.
My mother once inherited a Fortran program. It had a single variable, called āaā. āaā was an array, and each index was used for something different. nice!
In early versions of FORTRAN you had to represent every data structure imaginable as an array, because thatās all you had for structuring data. People got very creative, and many interesting efficient encoding techniques were invented to work within the limits of arrays.
yes, but you still didnāt have to make a single array to hold everything
āI grew up programming in Assembly. Later they made me use a high level language (FORTRAN), but I still basically program in Assembly.ā
āI grew up programming in C. Later they made me use a higher-level language (C++), but I still basically program in C.ā
ā¦
haha, nice. Most of my commercial programming at the start was in 6502 assembly, and some 8086 assembly. But it was always a pain. Switched to C when it was practical on the PC, then C++ when Borland released it (1991). Since then Iāve used languages that are basically the same, with some side excursions into JavaScript and Lua, which are quite different. ATM the project Iām working on is mainly in TypeScript. That language is pretty nice - I like it. Anyway, pretty sure my code doesnāt look like assembly ;-). I think there must be a lot of old C++ programmers on this project - we use all the compiler options that force you to declare everything, and require semicolons. Fine with meā¦
My point about naming is about whether or not the things being saved (which hasnāt quite been determined) are semantically different enough that names are useful. For example, Iām certainly glad that VCV modules have names; Iām glad I donāt have to refer to module 231 or 609. On the other hand, having to name all of your array indecies would be bad, too; volt1[āoneā] = volt1[āzeroā] isnāt always an improvement.
Anyhow, rather than discuss generalities, Iām far more interested in use cases/examples. If you had the ability to save state in BASICally, what code would you use it with?
In my case I usually want it to be available next time I start the patch.
In my case itās always something tiny.
My BASICally scripts are incredibly simple, so naming is not an issue.
If the values are dumped somewhere (i.e. āmyexport.txtā) then Iād probably manually reshape it to be acceptable for Voxglitch One Point. .
Or Iād just create a new BASICally module with another code. In case of the original example Iād create a new module with this code:
' this is the twinkle super star pattern :)
if in9>2 or start() then pos=-1 end if
volt1[0]={0.00, 0.00, 0.58, 0.58, 0.75, 0.75, 0.58, 0.42, 0.42, 0.33,
0.33, 0.17, 0.17, 0.00, 0.58, 0.58, 0.42, 0.42, 0.33, 0.33,
0.17, 0.58, 0.58, 0.42, 0.42, 0.33, 0.33, 0.17, 0.00, 0.58,
0.58, 0.75, 0.58, 0.42, 0.42, 0.33, 0.33, 0.17, 0.00 }
' calculating the next step
pos=pos+1
' sending out the first eight of the voltages
out1=volt1[mod(pos,8)]
' maybe this for a mydebug.txt?
debug.print volt1
@FiroLFO, A couple questions to drill into your specific instance a bit more:
-
Is the action of turning a variableās value into a string something that is initiated:
1.1 programmatically, that is, some code running causes it to happen?
1.2 by a human action (say, by selecting something in the context menu)?
1.3 Something else?
-
Is the best place to put the resulting text:
2.1 the copy/paste buffer?
2.2 Wherever the cursor in the program text is (i doubt this is a good answer)?
2.3 Some file with a well known name?
2.4 Some separate place in the module UI?
more āstandardsā for stuff on the clipboard would not be a bad thing.