Glenn Stanton

i found this in my inbox a few days ago. it's a nice course which gets you thinking about how orchestration should use "color" instead of "range" when select instruments. https://welcome.online.berklee.edu/Orchestration-Techniques-Course.html

i thought your Jag could hit 12K RPM before it begins to act up... ?

the latter as who could object to the former? ?

a blues song about the plethora of underwear and general undress in advertisement today... ?

from my test electronics days - we'd consider anything 5Hz and under to effectively be DC so blocking anything below 10Hz was fairly standard to avoid issues with the DACS. from a musicality standpoint, unless you're doing something with large pipe organs, cutting anything below 20Hz would likely solve this. for VLF "effect" like gaming and theater effects - i'd put those on a separate "effects" track and ultimately route to the appropriate effects channel (if there is one).

2¢ more - any time you are "stacking" multiple selections on a single control (like output or input) you run the risk of these being hidden from general view and could result in people having problems with changes or troubleshooting... i like the idea of "MIDI sends" for when you want to assign the output to something else specifically and when looking at the track can see it (unless you have lots of them so they're hidden). or a "patch point" (as a send and/or output assignment) where any track can select it as an input (or really any MIDI input on a synth or track). for me, an "aux" track is just a convenience to setup a patch point + related track so that would be consistent with the audio side of things. these two approaches would seem intuitive and not result in (too many) "hidden" connections and provide folks with "absolute" routing paths when desired. on the sends it would be nice to have filtering options (like we have volume and pan) like notes or CC, ranges, etc. on patch points - i'd keep it simple - the consumer manages the content they get from it. this avoids possible man-in-the-middle complexities like when you're trying to tweak something at 4am and end up pulling hair out trying to remember why the wrong stuff is happening when everything seems to be set ok... ?

that is what i usually do - select multiple ones then the target, however it would be nice for the one-offs to return to the uncategorized list rather than the target list and the resulting scrolling...

definitely patch points would be a plus. a huge plus. however, scook's using a plugin or MIDI generator as a source across all tracks is valid and easy to do. i use RipChord and Scaler 2 and some free MFX plugins as well as the FN42.

i just disable it in the device manager rather than delete it. i use this same tactic for a number of other bits as well since the OS finds and installs drivers for them regardless, however, disabling them means they're still in the system and so no further attempt is made by the OS to re/install them.

maybe something got fixed so which ever track is selected first is the "primary one"? there are a number of software products that behave like that, and its possible someone called out the arbitrary nature of running a CAL on two or more tracks and the Bakers decided to force the first selected as primary. for myself, i simply merge two (or more) tracks into a new single midi and then run my CAL (or MIDI plugin) on that.

this looks like it's intended to run on a single track. one option - lock one of the clips so the delete cannot happen.

i see a function in "throw exception pOforRichard(random(date-4))" not sure if this specifically for you though ? it is a good idea to try and save as a normal project and determine if the clips are all there or not. although the vox missing might be a signal from a higher power that you need to re-track those anyways ?

to be fair, my rack unit - UMC-1820 - i can get to about 2ms at 64 samples. not useful in practice when recording multiple tracks on my current systems, so i usually set to 6-8ms @ 128 samples with no FX when recording live instruments. for MIDI controller performance i'll go to 20-30ms @ 512 samples, and mixing, 100ms @ 4096 samples. if the monitoring is happening later in a mix cycle, and i need to add live instruments, i switch to direct monitoring of the new tracks and play to the mix level latency. then simple move the new tracks based on the samples #. least amount of potential glitching and it's digital so moving tracks precisely is "normal" for me. maybe when i finally upgrade to a proper modern system, this approach will not be strictly necessary...

i have the latest version and its there... however, if there is no content in the selected track(s), the option is grayed out.

are you stretching any audio? (vs MIDI instruments)? are you sure there are no tempo changes being set (perhaps in a template you made)? look at the tempo map to be sure. i know ive done things like change tempo with audio files without going through the steps to proper stretch the audio tracks.

on my system with a Behringer UB-802 on USB 2, i'm getting a reading of 10ms @ 480 samples. have you run the wave profiler on driver settings tab? under audio sync and caching i believe you can make this adjustment which might help.

looks like its a dead link

the downside of modular choices - how many busses did you need? or tracks? i think over time you define what is the most likely combination of tracks and busses you typically use and make that your primary template. then create the other track templates for expanding your project. i have a single large "template" template which has my full set of tracks and busses, and when creating a new track template, i use that to add the new track, set up the effects, sends etc. and then export it. if i have existing busses that match up - the track is simply added and wired in. if the project doesn't have the associated buss(es), then they get added and the track is wired in... so my primary template has maybe half the total number of tracks and busses and i have another 30 or track templates for specific instrumentation and their associated busses. the main annoyance is the buss colors not being preserved and thus the track colors are not...

maybe an mp3 file is the only [surviving] copy of something (think old cassette tape ? ) and you need to do some edits - example - you get an mp3 from someone's mp3 recorder of an important meeting but want to run RX on it to clean it up - so converting to WAV first then running through a series of fixes (some may be destructive writes) - and then re-export as mp3. obviously not the same as buying things and getting them as mp3 when they should have been WAV (or other lossless format)...

you could just create presets to reuse things. i have made about 50 custom presets which include sonitus and PC, waves and PC, slate and PC, etc variations of eq, compressor, effects, etc which i can readily load and tweak. this way if my template defaults are just right, i load up the waves or slate variations and tweak if necessary. saves a lot of clicks and time ? then like other presets you can select multiple tracks or busses and load them in one go (like you could with FX Bin)

i almost never use the track FX bin as most of the stuff i'm using is the in the PC modules. so i use the PC FX bin/chain for presets that include non-PC/VST/DX modules like compressors, effects, etc. then with a bunch of presets, it's easy to add them across tracks and busses. and tweak. plus my templates already have the bulk of PC modules per track and busses setup.

coolio

why not use the techniques forum here? many people are leaving facebook.

looking at the list it would appear that each of Mark's test where an increase of 10 is roughly an octave (20, 40, 80, 160, etc). but if you produced a finer granularity for your own as testing as Mark described, you could likely map to whatever range you wanted. it's likely different EQ types will have different slopes so you may want to test for each of the 4 EQ types.

sadly it's only for paid subscribers.