Thanks. I need to spend some time looking at the txt file patterns. The arp-demo.txt file I am using in my first tests has $h1=1, so that explains why I am getting an arp note and one harmony note out of tcArpGen.
But, what determines how many channels there are on the note output? Is it always going to be 4? I’m not sure what to do with the 2 output channels that have 0v or C4. Looks like the poly gate out for those two channels is also 0v, so gate is off and FM-OP will not be gated on these channels?
Yes, the poly v/oct output and poly gate output always have 4 channels and the gate value for each channel determines whether a note channel is on or off. Modules that take a poly input and poly gate should apply the gates in each channel to the corresponding v/oct channel. For a nice visual example, send the poly v/oct out from tcArpGen to SurgeXT Sine VCO, output from Sine VCO to SurgeXT EGxVCA, and poly gate outut from tcArpGen to EGxVCA. Load a rule with multiple harmonies, semi-3.txt for example, and watch the gates rise and fall in EGxVCA.
Thanks Bill. At this point, I just need to do a lot of playing (I mean testing ). I am very pleased with tcArpGen so far, I will definitely be using it in my music.
The patches are saved as a compressed archive so patch assets can be saved into it (via json, which is the uncompressed patch format). That way it travels with the patch if shared. Just an idea
Unfortunately, I have multiple issues wit\ tcArpGen 2.0.3:
I cannot load my patches that have tcArpGen 2.0.2 in them. Rack crashes when the patch loads. The last thing in the log file is… well now it does not crash. Any way it was saying the Rack JSON manifest had been loaded. In the meantime I had created a new patch that uses tcArpGen and Meander and that seems to have fixed up the manifest issue.
I thought tcArpGen 2.0.3 was not doing Poly External Scale properly, but my patch crashed Rack again, so something is still wrong. Although there is no crash message in the log file, there is a tcArpGen load error:
Did either the patch format or the rule format change in this version. Or the data JSON format?
Edit: Also, the scale format is not being saved into the patch file.
Edit: The "cannot find start rule " error was probably caused by me creating a new patch but forgetting to select a System Rule File in tcArpGen. Not sure.
Edit3: Well, if I try to connect the Meander melody note out cable to tcArpGen Poly-In V/Oct, Rack crashes with no error message. Probably this has to do with Meander melody out being monophonic. Since I had to start my patches over due to crash, I no longer have everything setup correctly for tcArpGen. This is going to be tedious.
Hmm … sorry about that. The json format changed, but that should be backward compatible so that items not saved from a previous version are gracefully defaulted until the patch is saved in a new version. There is an additional input (the Key Order CV input), but that was added to the end of the inputs[] array so it does not disturb any previous input ids. I did do some refactoring in the code that supports scales, and some scale related info is stored in the json format. It could be that the scale info saved from the previous version is producing wrong scale notes at startup, but a full on crash seems unlikely.
The ‘cannot find start rule: S’ message happens when the arp rules file is loaded and does not contain the seed ‘S’ rule. That happens when selecting a rules file that is not a valid rules file. The path to the rules file is stored in the json data. On startup, the module reads that path from the json file and reloads it. If the file does not exist or has changed to no longer be a valid rules file, then the ‘cannot find start rule: S’ message appears in the log file. Or … it could be (probably is) a missing check in the code to see if, in fact, a valid path was loaded from the json file. This seems the most likely to me. I will investigate.
Good catch on the ext scale format not being persisted. Will fix that.
I’m pretty much dead in the water. Any existing tcArpGen patch I choose to load results in a crash with no error. That then triggers off confusing error cascades on subsequent loads. This last time, my existing patch file loaded and seemed to be working correctly, but I saved the file and reloaded and it crashed.
Updated the json code to be more careful about handling the rules file to load, and to save/restore the ext scale format Let’s see if that fixes things.
Sorry, but although one of my patches seemed to work with this latest, after saving a re-loading, that patch will no longer load as it causes a Rack crash with no log crash info.
I think I have run out of patches to test on. Actually I tried one I had not tried today and it crashes on load with no log error.
hmm … I downloaded the demo patch you posted earlier in the thread (built with previous tcArpGen version) and it came up fine for me with the current tcArpGen version. No issues other than the rules file not being loaded because the path to our user folders are different
Are you able to create/save/restore new patches with the updated tcArpgen?
The quick answer is “apparently, yes”. I created one with Meander providing the Poly Ext Scale, and tcArpGen is picking up the scale fine. I don’t have tcArpGen generating an arp, etc. as I have not set everything up with polyphonic v/oct and gate from Meander. I will do that, but I am going to create some revisions from this patch so that if it crashes, I have a good restore point to go back to.
I’m not sure of your level of experience developing for VCV Rack, so please forgive me if you know all of this.
For Meander, I learned the hard way how necessary it it to code pre-emptively so that compatability issue crashes are not introduced as new features are added (and sometimes removed).
My key points are:
Always initialize all variables so that crashes will not happen on uninitialized variable usage.
in json todata and fromdata, make sure to handle missing tags gracefully. Check for null pointers before use.
Be very careful in adding and deleting parameter and port ID’s
in my iterative test patch, Rack crashes as soon as I connect a v/oct or Gate cable to tcArpGen V/OCT or Gate Poly In, regardless of where the cable is coming from. Have you changed the port IDs on either of these. perhaps? This happens regardless of which mode the poly scale input is in.
I took Meander out of the patch, just in case, but results are the same.
No, those port IDs have not changed. The only change related to ports and port IDs is the addition of the Note Order port that was added to the end of the inputs array so as not o disturb the other port numbers.
Curious to know if starting up a new project with only tcArpGen loaded (or very few modules loaded) and then connecting tcArpgen outputs to tcArpgen inputs shows the same crashing. If that works does it still crash when connecting the outputs from some other module to tcArpgen inputs?
I created a bare-bones patch with tcArpGen. When output is connected to input, the crash happens. Nothing is noted in the log. I created a bare-bare-bones patch and it crashes when output connected to input.
The only time I experienced a crash with cable attachments in Meander was when I changed up my code to detect cable attachments and detachments. Turns out I was accessing something associated with the cable before it was in the logical connected (or complete?) state. That was a CableWidget->isComplete() success before doing anything else on the cable.
). I am very pleased with tcArpGen so far, I will definitely be using it in my music.