Amberwolf

Usually arp is done to the midi before it reaches the synth, if it's not an internal function of the synth. I don't know about the modern Sonar, but my ancient one has an arp in each midi track, though it is not as easy to use or as functionally elegant as it could be (thsi may have changed). This arp effectively works like an MFX in the bin, applying in realtime to the clips in the track, or can be bounced to new clips, etc. You can do quite a bit of stuff with it. My track Just Give Me A Voice has a piano / strings interplay that was created using the per-track arp to make the midi clips based on my playing, then I edited the resulting clips to create the midi that then drove the sounds you hear. Each sound I used has a different velocity curve, so t hey both respond differently to the same MIDI. Usually I use the arp that's built into a synth if it has one, and almost always I use Z3TA+2 for synth stuff (which also allows you to use your own MIDI pattern for the arp).. There are also other arp fx, probably some VSTs for this, and somewhere I have some arp MFX I thihk, but haven't used them enough to even remember their names. Some arps dont' ahve all the features needed to be really useful, but generally they'll need to have a way to either run free at whatever time signature or tempo they are set at, or to sync to host, and wehther or not to restart the pattern on every note you start, or simply jump into the pattern at that point in the sequence so the pattern stays locked to the song's measure/beat, etc. Some arps have no velocity modulation built in--if you press a note at a velocity, all the notes in the arp pattern will be at that velocity. Some have velocity for each note in the pattern, and teh velocity you play determines the base velocity these are modulated around. Some primitive arps only play at the velocity they were set to or patterned at, and dont' respond to your actual note velocity. Etc. VBeing able to create my own patterns for an arp is a necessity, and being able to export the pattern already there (drag to a lcip, bounce to a clip, etc) so I can edit it and do what's needed with it, is another one. You might not need this...but if you could do it you might find a universe of possibilities. I often play arped stuff to delays, usually some form of pingpong, often a 3/2, or a specific time like 450ms one side, 600 the other, and may have to edit the pattern to work with that.

Does the Printscreen key on your keyboard copy the screen to the clipboard? If so you can paste that into Paint (or whatever) and save it as a file.

More thoughts, not knowing much about your system or instruments' functionality (just general observations of software): But it could be caused by one of the instruments being played, having some issue that is causing an overload of it's own buffers or audio stream or playback engine. If any of the instruments has had an update to it's engine or other software bits, that might cause it. If that one spot happens to call a sample that isn't used anywhere else, and the sample is damaged or if it's one of those instruments that updates it it's samples, it might be a cause.

Those used to be called WORM memories--write once, read many. In the days of fuse-roms, they called them OTPs, one time programmables... Good grief I'm old.

If it *was* in roman numerals, it would be much harder for them to confuse the two.

Was worth a shot.

Were there any updates to anything involved between the time it wasn't doing this, and the time it started again now? Automated updates to OS, or drivers, or software? Or manual ones? If so, it could be directly related, though rolling back might not change it depending on what exactly caused it.

So that everyone isn't wasting a bunch of time getting you to try things already done, you need to list all the things already suggested and tried, point by point, and their specific results. Describing your complete setup, including how the project is routed / bussed internally, will also help us help you.

There are actually ways to include this in your final output if you really want to. Your simplest way is to record this output realtime into your mixing device, then get that file back into the computer as a wave file you can then encode into mp3 or whatever format. (keep in mind that depending on the encoding choices it can change the sound of your file). A more complex way to setup is to use an audio loopback driver, if you can get one to "connect" to the *output* side of your hardware's sound driver, but that's something you'd have to figure out...the previous way is easier to do.

Also, if it just sounds different played back on something else other than the monitors you use for mixing, or the room you're in when mixing, that might mean you need to treat the room, or it might be the other playback speakers or spaces are just really different from your monitors. One way to minimize this is to have several sets of monitors including cheap speakers, headphones, a tv soundbar, etc., all connected to the output of your system thru a switch. Then change from your main monitors to test your mix now and then, to each other listening devices.

In my experience, it's probqably not the file name length, but the many files involved (often tiny, but not always). If you have USB3, it's pretty danged fast as long as the port, drive/enclosure, and cables and any hubs in between support it. The biggest slowdown I've found so far is when the SSD / etc "write cache" (of whatever implementation) is filled by the transfer so the whole process is then slowed down as it has to first write all that to the flash locations it stays in, then clear that cache before it can accept any more data. That's a slow process for some drives, and some drives have very fast but small caches, whcih work great for typical usages, but not so great for huge data transfers and sometimes not for our type of usages with mutliple big file writes. The Samsung Evo SSDs I have are terrible at these things, but the Crucial SSDs are much faster. Both are in the same model and revision of the Sabrent USB-SATA cases, and have been tested on the same ports on the laptop, and the same hubs when that's needed. But they're all faster than the internal spinny drives I've got.

Guess it depends on why the problem exists within a specific person, and what the specific reactions that person has to the problem. If it's something that causes anaphylaxis, it's probably not a good idea to try that method.

Those are all questions you'd have to pay a lawyer to answer with even a remote bit of certainty...and the reality is that until it is tested in court, you still won't know the answer. Every person you ask is likely to have a variant opinion. Since none of them is likely to be the one dealing with your specific legal situation for you when something happens, what they say doesn't really matter. You can ask the companies whose services you will use to see what they say, but unless they are providing you with legal certainties in documented form, and you have a lawyer to interpret them all for you, those are probably not the final answer either.

If you're up for just the previous version, 22, it's in a humble bundle for the next couple weeks. Lots cheaper than the manufacturer site.

note that many if not most ssd type storage is only fast for a tiny amount of data at a time. after the "cache" (different terms, same idea) is full then everything slows way down. nearly none are as fast as they claim to be for any kind of sustained write operation.