TLs-2095-LA Released (updated v1.1)
-
- KVRAF
- 5139 posts since 27 Jun, 2004
ddummer, GTK is very widely supported, and some programs compiled for Windows use it (like Xchat) so other than issues you might run into with programming with it, no real restrictions. Other than GTK, I don't think there's anything else as "standard".
-
- KVRAF
- 6478 posts since 16 Dec, 2002
I've been wanting to port my plugins to linux (GUIless but free) for a long time, but it seems there's just about no stable platform for it yet.ddummer wrote:Any downside using this GTK thingy for Linux?
When I see someone like aciddose struggling with compatibility problems there, I think it best to stay away until the situation with hosts is improved dramatically.
-
- KVRAF
- 1907 posts since 29 Oct, 2003
As a "pusher" who started this linux talk, just a question: would it be rational for developers to hook to eXT2-linux vst support or rather to wait for "something stable" to emerge (if and when) ?
THERE IS ALWAYS A WORKAROUND
-
- KVRian
- 666 posts since 29 Dec, 2006 from Auckland, New Zealand
Another useful plug from TL. nice nice nice.
Thanks plenty
Heres a drum setting that worked for me with this gear.
I used it on... (what is it called again?) the drum stem which consisted of Kick, Layered Clap/Snare/Snap and another ghost snare and kick. *Note: No other percussion (highs etc)
I think its far from text book, but the result I got with this is sharp and snappy.
In this order...
what are those red lights??? No!!! heh.
Just experimenting, sounds good, Constuctive cricisizem welcome....
but flaming is cool too
Thanks plenty
Heres a drum setting that worked for me with this gear.
I used it on... (what is it called again?) the drum stem which consisted of Kick, Layered Clap/Snare/Snap and another ghost snare and kick. *Note: No other percussion (highs etc)
I think its far from text book, but the result I got with this is sharp and snappy.
In this order...
what are those red lights??? No!!! heh. Just experimenting, sounds good, Constuctive cricisizem welcome....
but flaming is cool too
-
- KVRAF
- 6478 posts since 16 Dec, 2002
I've been getting familiar with this compressor a few days now and I have to say that the forceful push it generates reminds me of the neve 33xx whatever it's name is, although the 2095 isn't as predictable. But this is actually an advantage since it's kind of more natural action that way.
then again it does transparency really well.. apparently:
There are very few compressors that handle full range piano performances with grace but this is one of them. It just sort of contours the instrument just right, without pumping it needlessly. It's still a pain in the ass to set up because trial and error is the only way as it's a bit unpredictable most of the time. I guess that's part of the fun.
then again it does transparency really well.. apparently:
There are very few compressors that handle full range piano performances with grace but this is one of them. It just sort of contours the instrument just right, without pumping it needlessly. It's still a pain in the ass to set up because trial and error is the only way as it's a bit unpredictable most of the time. I guess that's part of the fun.
-
- KVRAF
- 6478 posts since 16 Dec, 2002
a stable ext2 for linux is what I've been waiting for. it's not quite ready for any kind of serious adoption yet, let alone as part of a predictable development environment.mauseoleum wrote:would it be rational for developers to hook to eXT2-linux vst support or rather to wait for "something stable" to emerge (if and when) ?
-
- KVRAF
- 1907 posts since 29 Oct, 2003
I thought something along those lines.
Otoh, afaik NO actual real-life compressor has "static", or stable time reactions for attack/release. These are all program/input amplitude dependant, as any RC circuitry, even if CCS's are used, and even if opamp full wave rectifiers are used, and even id PCM fetchoppers are used. So, it should be natural for digital devs to use program-dependant attack/release, because this is how hw stuff behaves. (Anything like variable caps /with opamp/ as seen in that's sheets are exageration of existing phenomena, as well as "dual" recovery circuits - with fast/slow rc circuits)
So there ... it's an inherent characteristic of a RC circuit, probably more so evident in attack detecting, because it's directly current-fed, and more voltage=more current=faster charge unless there's already some voltage existant in detector, then detection happens faster, too.
Wow, that was smart innit ... and ain't really valid for opto/vac compressors.
Otoh, afaik NO actual real-life compressor has "static", or stable time reactions for attack/release. These are all program/input amplitude dependant, as any RC circuitry, even if CCS's are used, and even if opamp full wave rectifiers are used, and even id PCM fetchoppers are used. So, it should be natural for digital devs to use program-dependant attack/release, because this is how hw stuff behaves. (Anything like variable caps /with opamp/ as seen in that's sheets are exageration of existing phenomena, as well as "dual" recovery circuits - with fast/slow rc circuits)
So there ... it's an inherent characteristic of a RC circuit, probably more so evident in attack detecting, because it's directly current-fed, and more voltage=more current=faster charge unless there's already some voltage existant in detector, then detection happens faster, too.
Wow, that was smart innit ... and ain't really valid for opto/vac compressors.
-
- KVRAF
- 6478 posts since 16 Dec, 2002
had you mentioned "auto" or "program dependent" release and attack networks hidden in most good designs, ie. you control the shapes with variable serial/parallel (depends on the design and can be pretty complex) cap charge networks, and this would be like the prodigy pro forums. This is done in opto/vactrol and even vari-mu designs quite often as well, but it's a bit harder to design it in those. In other words, trial and error and listening tests are the only way, just like daniel did with his compressor here.
a great place that prodigy pro forum, in case you haven't been there yet.
a great place that prodigy pro forum, in case you haven't been there yet.
-
- KVRAF
- 1907 posts since 29 Oct, 2003
Been there. Although my main point of interest were gyrator based *things*.
But ya - except networks - my point was that any detection circuit that is current-based (and you _can't_ escape that, either RC or vac, which is also chemistry) is inherently program-dependant, let alone more funky designs.
Quite some time ago I had longeish email exchange with bcarso about LM13700 hack which allows it in more "pro" setups (13600 used in TLAudio f.e.), for obvious reason of it's _tight_ stereo tracking vs. fets, f.e - and possibility to use it as a variable resistance. Second thing was how to construct a good semi-auto recovery network - which had to be converted to variable current source. I think I still got That's whitepapers somewhere for their networks. Nevermind ... didn't have time for that anyway.
But ya - except networks - my point was that any detection circuit that is current-based (and you _can't_ escape that, either RC or vac, which is also chemistry) is inherently program-dependant, let alone more funky designs.
Quite some time ago I had longeish email exchange with bcarso about LM13700 hack which allows it in more "pro" setups (13600 used in TLAudio f.e.), for obvious reason of it's _tight_ stereo tracking vs. fets, f.e - and possibility to use it as a variable resistance. Second thing was how to construct a good semi-auto recovery network - which had to be converted to variable current source. I think I still got That's whitepapers somewhere for their networks. Nevermind ... didn't have time for that anyway.
-
- KVRAF
- 6478 posts since 16 Dec, 2002
what we really need is Elysia's research on this. From what I hear they wipe the floor with existing variable current source designs (possibly in the said "auto" networks) with their Alpha compressor. Unadulterated brute force methods used there.mauseoleum wrote:Second thing was how to construct a good semi-auto recovery network - which had to be converted to variable current source. I think I still got That's whitepapers somewhere for their networks.
-
- KVRAF
- 1907 posts since 29 Oct, 2003
... expensive territory ...
-
- KVRAF
- 14740 posts since 19 Oct, 2003 from Berlin, Germany
You know that the EQ/Body stage is added AFTER the brickwall limiting, right?Dayl wrote:
-
- KVRAF
- 6478 posts since 16 Dec, 2002
no doubt. I'm not in the market for such ridiculously overdesigned and expensive tech, but I wouldn't mind knowing some of it's secrets.mauseoleum wrote:... expensive territory ...
