i'm releasing these patches. they are a bit of a hassle to use because they come in sets of 10 different patches. you have to use a different patch for each amount of kernels from 1-10. so all 4k programs use the 4k patch, 8k use the 8k patch etc.
there are 2 sets. one actually switches the clean and even kerns to timed mode, the other just maxes out the default lengths for timed and freqd modes, making it quicker/easier to switch to timed if you want to wait until rendering to do it.
i'm not supporting these or anything and you shouldn't be messing with them if you don't know what you are doing. both sets have long detailed instructions on what i think is probably the quickest way to use them. the txts also absolve me of any badnesses that may happen as the result of you using the patches improperly or even properly, from now until forever (in fact, just don't use these patches, even though they will probably work if you follow my instructions), and they repeatedly remind you to backup before patching which should prevent any actual damage from being possible. the txts also go over some things to consider about the patches.
etc etc etc blahblahblah.
use them or don't. beyond the time i've already spent making them, i don't really want to spend any more on them but i guess i might answer some questions about them or MAYBE consider suggestions for other patches if they are good ones. MAYBE.
i'm not trying to be a d*ck about this, but the main point i want to get across is that i've done my part here, and the rest is on YOU as far as these patches are concerned. if it's even worth your time to use them, since they are a bit of a nuisance to apply (because of kern amount issue), is up to you to decide. if anyone has trouble applying them i MIGHT try to help if i have time, but if i sense that the real trouble is that you aren't savvy enough with NAT and patching or even windows file systems (and i don't know anything about macs) and how to handle files (i'm talking about basic computer skills), i won't spend time trying to help you figure that out. i explain it pretty well in the txts.
and the main thing is i can't stress enough, to make backups first. i released these to maybe help some people have things work closer to the way they want. what i really don't want to see is anyone destroying their library with these patches.
if you apply a 5k patch to a 3k program, it's ruined.
oh and, i've tested these myself and they seemed to work as i've claimed they will, but if someone somehow gets otherwisely differented results, let me know and i will try to fix them. so in that sense i will 'support' them, but only if they are somehow wrong. i'm like 99% sure they work as i describe though. and when i say 'support', i mean, 'stand by'. like i will stand by the claims that i make that these patches will work as i say they will, as long as you follow my directions. i won't support them as in adding small extra anythings or fielding complaints about how they didn't make you a cup of coffee in the morning.
also, i MEANT to post this in the 'working with forum'.. for whatever that's worth (so if anyone at acustica wants to move this thread...).
Thanks Tim! Great patches! I've noticed, that the FREQD length goes to 13.5 when it was 10 before. This results in a slower program rate. Could you tweak the patches so they don't change the FREQD length? The TIMED length can be changed in the MAST page by setting the maximum TIMED length. Thanks in advance!
hmm.. yeah i thought that could become an issue, and i did mention it in the txts. i hadn't really thought about the prog rate change that could happen which then becomes a bigger issue...
ah but, thinking about it NOW, i'll pose a question back at you: what about the fact that the timed length will still be set to 13.5? if i make your change (which at first i was actually considering, until i thought about this), then freqd will stay at 10, but timed will go to 13.5. so any issue caused by the prog rate change will not be noticed if you just listen in freqd, then switch to timed just before render. prog rate will then change when you switch, and it will alter how the program reacts. you wouldn't catch it, and now your render is different from what you heard before.
on the other hand, even if you kept this fact in mind, and decided to lower the timed from 13.5 down to match freqd 10ms before render, that negates the whole point of the patch. the whole point was so you wouldn't have to make any adjustment to length.
so as i see it now, there isn't any change to make to the patch that would solve the issue.
i think if timed length is going to change and result in a different prog rate which will affect the sound, the best thing is for freqd to also change so that people will hear that change before rendering.
if you can think of some great way to deal with this, i might comply, but i can't imagine what it would be.
i guess this should just be chalked up to the fact that some programs aren't really compatible with this patch, and this is an example of one of them. if the length is being changed to the extent that the prog rate changes, you might not want to use these patches for that program (especially if we are talking about a compressor where the prog rate is extra important).
my question is how exactly did you spot the prog rate change in the first place? lots of people, including myself, might have missed it. if you are patching lots of programs, how would you keep track of what the previous prog rate was for each one, to know it changed for any of them? this is yet another reason why i can't really 'stand by' these patches. if you know what i mean. they aren't an ideal solution.
I didn't patch a lot of programs, they were all kind of the same. Before the patch, both TIMED and FREQD were 10ms. And after the patch, FREQD went up to 13,5ms. I don't even see why or how the patch increases that length. In the KERN page at the top one can see the program rate. Do you think it's possible to make a patch which sets the FREQD length to a specific value? (10ms)
yes it would be possible to do that but i don't know if i will... maybe. i am working on a project right now that's gone past when i wanted to release it. plus i'm not 100% sure how i feel about the fixed time idea. here's why- most comps are set to 10ms when you open them on default, but probably not all, so if i make one that's set to 10ms people will think it's for comps, and think it will always work for comps, but it might lower the length for some. then i could make another set to 50ms like most preamps are at default, but not all are and again it becomes the same slippery slope as before. BUT since 10 and 50ms are the most common values i might do it as another option.
the reason why they change the length? it's because that length is already there to begin with. open those programs (non-patched versions), go to kern page, and adjust the length. you'll find that you can adjust it up to 13.5ms. my patches just set the lengths to 'max' (up to 80ms), assuming that the freqd length in use already is. some times it isn't. it depends on how the dev made it. see, there's too many variables to make a patch that would work in all situations.
i'll tell you what, instead of me releasing other patches, here's what you can do. make a copy of the patch set yourself, and just open them in notepad. find the number 80000 and change it to 10000 for 10ms, 50000 for 50ms. yeah it will be a bit tedious, and that's why i wont do it
but now you know how it works and can make it however you want. i think the ot1 entry is for timed length and the ot2 is for freqd. -tim
enriquesilveti wrote:Request Giancarlo a NAT batch for that like the GDRIVE NAT batch.
it's possible that somehow these patches could be improved, but i kind of doubt it.
the reason for having separate patches- you have this entry in the program: <OT1> <LENGTH> XXX </LENGTH> <FADEOUT> YYY </FADEOUT> </OT1> <OT2> <LENGTH> XXX </LENGTH> <FADEOUT> YYY </FADEOUT> </OT2>
OT1=freqd, OT2=timed XXX=the kern length YYY=the fadeout time
the problem is that this entry shows up in each harmonic order's set of instructions, so a patch has to change it for each one. as far as i know there is no way to change length for all kernels at the same time from one place in the program code (which would allow one patch to work for programs of any kern amount). the 2nd problem is that if you apply a patch that changes the length for 10kernels to a 4k program, it then is adding code for 5k-10k, which don't exist. that permanently ruins the program. so that means you can't simply apply the 10k patch to all and expect it to cover them.
and for the other issue- in my opinion it's better to have both freqd AND timed lengths change, because if the change will force the prog rate to change, it's best that you HEAR that change when you first load the program, instead of having it happen only after you stop playback, switch to timed, just before render (in which case you won't catch the change in sound caused by prog rate change). but that is just my opinion, and i explained how the patches could be changed by anyone if they want to do it some other way.
i know the nebula program structure pretty well by now, and i don't see how they could be improved (but there could be something i don't know). the only other current option is doing each by hand, one at a time (which would be faster for a smaller number of programs). there might be some code you can put into a program that changes the length for ALL kernels at once, but i've never seen it so i don't know what it is, if it exists. i just did an experiment, tried an idea i just had for doing it all with one patch, and it failed.