bvideo

There's a thing called groove quantize that maybe you could use. The manual describes this in detail. Synopsis: First, construct one beat or measure of the pattern you'd like to emulate. Craft the timing and the accent you want to reproduce. Save that as a groove. Then you can apply that to a different sequence of nine notes to reproduce the timing and accents.

More than just separate tracks: when you are using the same synth patch, even using two different instances or channels, playing two of the same notes can sometimes cause some undesirable phase cancellations. Two different patches may be needed, or at least some detuning or chorusing. By separating the parts, you will guarantee yourself to be able to work around any unison problems.

I'm not familiar with any videos, but for sure some people here can help you with that. The Cakewalk pdf manual seems to be pretty clear about what can be done with groove clips. Importing is on p. 709, looping p. 711, finer points, including changing normal audio into a groove clip, in a few following pages. Find the manual under the "Cakewalk By Bandlab" menu at the top of this page. Or here.

A suspicion about Breverb2: what happens if you turn off plug-in load balancing?

Audiosnap & Groove/Loop are mutually exclusive. You could bounce it then loop it -or- just loop the original. A groove clip has usually been created such that enabling looping will get it to the project tempo as well as enabling the feature of dragging it for loop purposes.

Properties of tracks and buses, and also prochannel controls, clips, and now the arranger, are now all in the inspector pane. Type 'I' (eye) to open the inspector (or main menu views->inspector). Click on a track. There are icons at the top of that inspector - make sure the triple-horizontal-bar icon is selected, and there are the track properties. Instrument definitions are in the edit->preferences dialog (or just type 'p'), under the midi section. There is kind of a tree there, and with help from 'help' you can figure out how to configure your synth to always use the right bank select method.

The sysex shown is GS reset, meaning all patches are to be set to default? Then it must be the patches embedded per track in the file that are not being set properly. The post about reading banks maybe has a big clue. The instrument definition for the chosen synth has bank numbers and also an option that chooses how the bank number should be interpreted ("bank select method"). Perhaps the older versions of Pro Audio don't use that. From the help pdf: So check the bank numbers in your instrument definition file; also if it has "Controller 0 only", change it to one of the others & vice versa.

1 & 1/2 semitones is about the ratio between 44100 and 48000. In other words, if your plugin thinks it should generate audio at 44100 when your sound card is playing at 48000 or vice versa it will be that much out of tune. Does your project match the sound card setting? And does other audio in your project sound OK? Does Carbon Electra have its own setting for sample rate (unlikely)?

Sometimes a tempo-based digital delay will make scratchy sounds during a tempo change. If you see tempo changes around where you hear the noises, that's the clue that your digital delay in the "airy chords" preset is tempo-based.

I reported some anomalies in the mute & solo & input echo parts of the MIDI signal flow. A signal flow chart might settle some questions, including how prerecorded material merges with live input. Also bear in mind that there are some signal flow entanglements with instrument tracks and their synth components.

The Strike may be configured by default to not bother to send note off for instruments that have a constant short duration. It's configurable in the FX/MIDI page of Voice Mode - MIDI -> Note Off

Myabe you wanted 2048?

There are some confusing issues with MIDI ports in various versions of Windows. Try google: "windows limit of midi ports" This multiport interface works for me.

There's a thing called "snap offset" that can be set as a special property of a clip. Normally a clip snaps at its left edge to whatever landmark you're using in the track, such as "beat". The snap offset is a point in the clip that is used as the snap point of the clip instead of the left edge. It could be handy in the case of aligning a clip that has a pickup, strum, or some other feature before the first "beat" of the clip. (See help for "snap offset".) I don't know if it works for loops, though. Also, since loops are a multiple of beats long, the end of the clip would be short of the end of a beat by the same amount of its snap offset (if snap offset works on loops at all). That would be OK when repeating the loop.

Most likely the two different software implementations are different in how they define %. Rather than a standard acoustical definition, it represents a reproducible setting for the particular control. That said, your use of reverb on a bus with sends from different instruments at different values is one reasonable approach for saving CPU by using a single reverb. You may want to verify the sends are post fader (it's the default) if you want to preserve the mix value as you adjust an instrument fader.

If you are using MIDI long notes and expecting to start playback in the middle of any of those notes, that is almost guaranteed not to align with the rest of your score. The reason is that the DAW only has two choices when starting playback in the middle of any note: 1. start the note at the beginning or 2. don't play the note. In case 1, some kinds of synth voices can't possibly align when started at just any place in the score because they are being started at the "wrong" time. If you were to freeze those notes into their audio equivalent, you'd then be able to start playing anywhere. If you're not talking about long MIDI notes, then never mind. It must be something else.

In real life, true stereo is represented by relative signal delay between left and right and also reflections from the environment, maybe more than volume differences. One can also argue for differences in frequency response. The relative signal delay depends on the distance between microphones or ears. Reflections and frequency response also depend on microphone orientation and ear physics. Microphone orientation can certainly also affect relative volume as well as frequency response. You could try this on a signal recorded in mono: put the straight signal on left and the same signal delayed by a fraction of a millisecond on the right. With the same amplitude on both sides, the signal moves to the left. Experimenting with the delay amount can be fun. When considering how to reposition instruments (even when recorded in stereo), why not consider relative delay? One reason why not is listening (or mixing) stereo to mono can wreck the whole sound if only delay is used to represent stereo. A "true stereo" panner would have a lot of work to do.

Any tempo changes near 9 of the first one? Tempo-based effects?

One way: any controller can be modified using the event inspector in the control area. After selecting a range, that inspector can change values by n% or by increment +n or -n. By % would flatten or exaggerate the dynamics, while + or - would change the over all level, keeping the same dynamics.

What a pain. The Nord should have just shifted the notes before sending them. As it is, the track you record from the Nord would probably play back correctly on the Nord, but not on other synths. Also, most likely, the octave shift CC will not be sent when switching to a program preset that has a programmed octave shift. Again, not friendly to other synths. It's possible a CAL script could run through a track and replace all the CC 29s with the appropriate octave shifting. Hopefully the CC event has an included value to indicate which direction to shift. And beware sustain (CC-64) messages and also notes held across a CC-29. But the shift in a patch change probably won't be seen and may confuse your entire strategy. Also, what happens when you send MIDI notes to the NORD outside of the configured range? Would a track restructured this way still play back correctly? CAL is a custom scripting language built in to Cakewalk. If you have a programming background you could do it. There are also a few people on this forum that are so skilled that they might volunteer to do it for you.

Occasionally I notice late buffers show up when the song is just over, not while it is playing. No artifacts are heard... Also, my guess is the hidden "safety buffer" in some interfaces overcomes artifacts for slightly late buffers.

It's a hot topic here

Useful info here! But just to clear up my understanding about scheduling VSTi's? Normally there's just one VSTi serving any audio (synth) track. That is to say, the "synth rack" for that track only has one item in it, not a stack. This is clearly different from the case where an FX rack with multiple audio effects serves a single track (or bus). My understanding of plugin load balancing is that each audio effect in such a rack could get a thread simultaneously. That per track concept of load servicing does not even apply to synths. Your last paragraph implies a slightly different concept for synths; it doesn't sound like there is anything preventing running simultaneous threads on individual synths in the synth rack (it's global). In this sense, doesn't it make sense to say there is load balancing among the synths in the synth rack (and there probably always has been)? In this view, for a synth instance that has multiple parts, a single thread has to serve all the parts, even if the parts are directed to separate audio tracks (i.e. for the majority of VSTis, not supporting multithreading). Are there situations where Cakewalk would do multithreading to a VSTi that supports it? That would clear up most of my question (post 5?) about "overhead" of stacking synths. RAM is another part of the equation. For a VSTi that can support multiple ins & outs, how much difference in RAM does it take for multiple instances each with a single voice vs. a single instance with multiple voices. The code part should be shared. For a sampler, if samples can be shared between instances, I imagine there is relatively not a whole lot of difference. But how about for a synth like TTS-1? Does it wind up using a lot more memory for multiple instances?

I'm interested to know how mildly and how substantially overhead might be increased by stacking a mono-timbral synth. Also, I wonder if a multi-timbral synth can run multi-threaded.

120%