PS: the keyword I left out here is "memory bound"
On 26 June 2014 12:31, Andrew Simper wrote:
> On 26 June 2014 03:11, robert bristow-johnson
> wrote:
>> well, in the year 2014, let's consider that relative cost. how expensive is
>> a 1/2 MB in a computer with 8 or more GB? unlike MIPS, whic
On 26 June 2014 03:11, robert bristow-johnson wrote:
> well, in the year 2014, let's consider that relative cost. how expensive is
> a 1/2 MB in a computer with 8 or more GB? unlike MIPS, which increase
> linearly with the number of simultaneous voices and such, a large lookup
> table can be use
Still about the "simulation" idea: you've got to be aware of what you're
simulating, and what the proper theoretically founded simplifications
are that you apply, or you risk sounding, well, ehm, the same as a lot
of others who use similar approximations, or well, rather simplified
compared to
On 6/25/14 2:50 PM, Marco Lo Monaco wrote:
I will try to give my contribute about this last results in the discussion
to make it clear, even if I could hardly follow up all the details in the
superlenghty thread:
which is the point. so these iterations don't have to happen *during*
runtime.
T
In an effort to learn more on the topic, are there any suggested articles,
books, etc. that could help grok that basic machinery? I've been trying
to follow the thread (and earlier ZDF threads), but am waaay rusty.
I do have the PDF book Vadim shared a while back which I intend to spend
so
On 6/25/14 1:40 PM, Ethan Duni wrote:
which is the point. so these iterations don't have to happen *during* runtime.
At the cost of additional memory overhead, sure. Pretty much any algorithm
can be refactored in various ways to trade off runtime MIPS, memory
overhead, etc. Which implementatio
i forgot for the 2nd or 3rd time, but we need to take the [admin] tag
offa the Subject: header.
second, at the risk of being pedantic, i realized i didn't declare and
type everything to make the pseudocode legit with a compiler.
On 6/25/14 11:05 AM, robert bristow-johnson wrote:
float f
On 24.06.2014, at 10:16, Stefan Stenzel wrote:
>
> On 24 Jun 2014, at 0:37 , Urs Heckmann wrote:
>
>>
>> (Odyssee?) - fully analogue synths. That's currently the only way to get
>> something decent in hardware. Proper digital models seem to only make it
>> into software plug-ins.
>>
>
>
On 24 Jun 2014, at 0:37 , Urs Heckmann wrote:
>
> (Odyssee?) - fully analogue synths. That's currently the only way to get
> something decent in hardware. Proper digital models seem to only make it into
> software plug-ins.
>
Careful with such an arrogant claim, and maybe consider it might
On 24 June 2014 06:37, Urs Heckmann wrote:
>
> On 23.06.2014, at 19:18, robert bristow-johnson
> wrote:
>
>> it *is* precisely equivalent to the example you were describing with one
>> more iteration than you were saying was necessary.
>
> Now I'm really angry I wasted so much time. An example
On 23.06.2014, at 19:18, robert bristow-johnson
wrote:
> it *is* precisely equivalent to the example you were describing with one more
> iteration than you were saying was necessary.
Now I'm really angry I wasted so much time. An example is just that, an
example. I deliberately kept it very
>rbj
>>Urs
>Regarding the iterative method, unrolling like you did
>>
>> y0 = y[n-1]
>> y1 = g * ( x[n] - tanh( y0 ) ) + s
>> y2 = g * ( x[n] - tanh( y1 ) ) + s
>> y3 = g * ( x[n] - tanh( y2 ) ) + s
>> y[n] = y3
>> is *not* what I described in general.
>
>it *is* precisely equivalent to the ex
On 6/23/14 3:39 PM, Bogac Topaktas wrote:
On Mon, June 23, 2014 7:37 am, robert bristow-johnson wrote:
the other thing Urs brought up for discussion is an iterative and
recursive process that converges on a result value, given an input. i am
saying that this can be rolled out into a non-recursi
On Mon, June 23, 2014 7:37 am, robert bristow-johnson wrote:
> the other thing Urs brought up for discussion is an iterative and
> recursive process that converges on a result value, given an input. i am
> saying that this can be rolled out into a non-recursive equivalent, if the
> number of itera
-- cytomic -- sound music software --
On 23 June 2014 21:58, robert bristow-johnson wrote:
> On 6/23/14 12:43 AM, Andrew Simper wrote:
>>
>> On 23 June 2014 11:25, robert bristow-johnson
>> wrote:
>>>
>>> On 6/22/14 10:48 PM, Andrew Simper wrote:
>>
>> I think the important thing to note
Let me express my agreement with the nice choice of subject: the
simulation of tube amps. Of course during and before the advent of solid
state systems, some people may have laughed about the idea alone
(because tubes sound so annoying after while), but in the context of
guitars, it's usually n
hi Urs,
On 6/23/14 11:36 AM, Urs Heckmann wrote:
On 23.06.2014, at 16:37, robert bristow-johnson
wrote:
because it was claimed that a finite (and small) number of iterations was
sufficient.
Well, to be precise, all I claimed was an *average* of 2 iterations for a given
purpose, and with
On 6/23/14 11:58 AM, Andrew Simper wrote:
Ok, but where does
On 23 June 2014 22:59, robert bristow-johnson wrote:
On 6/23/14 10:50 AM, Andrew Simper wrote:
Ok, I'm still stumped here. Can someone please show me a reference to
how the bi-linear transform is created without using trapezoidal
int
Not sure about what you mean here, but to get these approximations, you
use the Taylor series of exp(x) and ln(x) for x -> 0 :
exp(x) = sum_(k=0 to N) x^k / k !
exp(x) = 1 + x + x^2/2! + x^3/3! + ...
ln(x) = 2 * sum(k=0 to N) 1 / (2k+1) ((x - 1) / (x + 1))^(2k-1)
ln(x) = 2 ( (x - 1)/(x+1) + 1/
On 23.06.2014, at 16:37, robert bristow-johnson
wrote:
> because it was claimed that a finite (and small) number of iterations was
> sufficient.
Well, to be precise, all I claimed was an *average* of 2 iterations for a given
purpose, and with given means to optimise (e.g. vector registers).
Ok, but where does
On 23 June 2014 22:59, robert bristow-johnson wrote:
> On 6/23/14 10:50 AM, Andrew Simper wrote:
>>
>> Ok, I'm still stumped here. Can someone please show me a reference to
>> how the bi-linear transform is created without using trapezoidal
>> integration?
>
>
> not that you wan
Here is a quote from one of my first replies to you Robert:
--
> of course a VCF driven by a constantly changing LFO waveform (or its digital
> model) is a different thing. i was responding to the case where there is an
> otherwise-stable filter connected to a knob. sometimes the knob ge
On 6/23/14 10:50 AM, Andrew Simper wrote:
Ok, I'm still stumped here. Can someone please show me a reference to
how the bi-linear transform is created without using trapezoidal
integration?
not that you wanna hear from me, but the usual "derivation" in textbooks
goes something like this:
On 23 June 2014 19:43, Andrew Simper wrote:
> On 23 June 2014 17:11, Ivan Cohen wrote:
>> Hello everybody !
>>
>> I may be able to clarify a little the confusion here...
>
> Thanks Ivan for your great email contribution. I will only reply to
> the one and only correction / clarification to what I
On 6/23/14 1:18 AM, Andrew Simper wrote:
On 23 June 2014 12:37, robert bristow-johnson wrote:
Andy and Urs, i have been making consistent and clear points and challenges
and the response is not addressing these squarely.
let's do the Sallen-Key challenge, Andy. that's pretty concrete.
With r
On 6/23/14 12:43 AM, Andrew Simper wrote:
On 23 June 2014 11:25, robert bristow-johnson wrote:
On 6/22/14 10:48 PM, Andrew Simper wrote:
I think the important thing to note here as well is the phase.
Trapezoidal keeps the phase and amplitude correct at dc, cutoff, and
nyquist.
Nyquist? are
Always good to have a nice interaction about the theoretical basis of
scientific work, and related practical implementations, isn't it ?
TO add a little positive note to the whole story, after maybe having
bashed some peoples' work in a "theoretically limited" corner too much
for their immedia
On 23 June 2014 17:11, Ivan Cohen wrote:
> Hello everybody !
>
> I may be able to clarify a little the confusion here...
Thanks Ivan for your great email contribution. I will only reply to
the one and only correction / clarification to what I have posted
previously.
> The bilinear transform is
Hello everybody !
I may be able to clarify a little the confusion here...
First, the MNA is a tool which may allow you to write and solve the
equations of any analog circuit made of resistances, capacitances,
inductors, mutu
On 23.06.2014, at 06:37, robert bristow-johnson
wrote:
> the other thing Urs brought up for discussion is an iterative and recursive
> process that converges on a result value, given an input. i am saying that
> this can be rolled out into a non-recursive equivalent, if the number of
> iter
I think you should look at this like a tool set. Table look up is one tool that
you can use as it iterative function evaluation. What tools you use depends on
circumstances. On the PC platform you have big caches, lots of memory and real
fast CPU clocks. If you go FPGA clock rate goes down as do
On 23 June 2014 12:37, robert bristow-johnson wrote:
> Andy and Urs, i have been making consistent and clear points and challenges
> and the response is not addressing these squarely.
>
> let's do the Sallen-Key challenge, Andy. that's pretty concrete.
With respect Robert, I have really tried to
On 23 June 2014 11:25, robert bristow-johnson wrote:
> On 6/22/14 10:48 PM, Andrew Simper wrote:
I think the important thing to note here as well is the phase.
Trapezoidal keeps the phase and amplitude correct at dc, cutoff, and
nyquist.
>>> Nyquist? are you sure abo
On 6/23/14 12:16 AM, Andrew Simper wrote:
you
have a function of two variables that you can explicitly evaluate
using your favourite route finding mechanism, and then use an
approximation to avoid evaluating this at run time. This 2D
approximation is pretty efficient and will be enough to solve t
>please at least try and understand what I wrote
> before sighing at me! Yes, I agree that for low dimensional cases this
> is a good approach, but for any realistic circuit things get
> complicated and inefficient really quickly and you are better off with
> other methods.
What I mean by "oth
>> you
>> have a function of two variables that you can explicitly evaluate
>> using your favourite route finding mechanism, and then use an
>> approximation to avoid evaluating this at run time. This 2D
>> approximation is pretty efficient and will be enough to solve this
>> very basic case. But e
On 6/22/14 11:24 PM, Andrew Simper wrote:
so whether it's a function of a single variable or a function of two
variables with your previous output in recursion, why not just explicitly
define that function and evaluate it? if it's about tube curves being the
nonlinearity inside, fine, use your i
RBJ: direct integration like I am proposing is a "good idea" can be
solved in many ways, what results is a set of linearised equations to
be solved, these can be for nodal voltages, or differences in
voltages, the latter is called "state space". Have a read of this:
DISCRETIZATION OF PARAMETRIC AN
On 6/22/14 10:48 PM, Andrew Simper wrote:
I think the important thing to note here as well is the phase.
Trapezoidal keeps the phase and amplitude correct at dc, cutoff, and
nyquist.
Nyquist? are you sure about that?
Yes,
no. you're wrong. again, try integrating (using the trapezoidal rul
> so whether it's a function of a single variable or a function of two
> variables with your previous output in recursion, why not just explicitly
> define that function and evaluate it? if it's about tube curves being the
> nonlinearity inside, fine, use your initial tube curve data in a MATLAB (
On 6/22/14 10:41 PM, Andrew Simper wrote:
It is different for a circuit that isn't a 1 pole RC.
no, it's whenever an integrator (1/s in the s universe) is implemented
numerically with the trapezoid rule. doesn't matter whether it's a C or
anything else.
RBJ: please show me the derivation for
>rbj
>another semantic to be careful about is "transfer function".
>we mean something different when it's applied to LTI systems
> (the "H(z)" or "H(s)") than when applied to a diode. the latter
> semantic i don't use. i would say "volt-amp characteristic"
>of the diode or vacuum tube. or if it
Can I say that I think there's a bit of confusion here:
>rbj
>>Urs
>>No, if we take a typical equation like
>>
>>y = g * ( x - tanh( y ) ) + s
>>
>>We form it into
>>
>>Y_result = g * ( x - tanh( Y_estimate ) ) + s
>>
>>as x, g and s are known, we simply use an iterative root finding
algorithm
>>(
>> I think the important thing to note here as well is the phase.
>> Trapezoidal keeps the phase and amplitude correct at dc, cutoff, and
>> nyquist.
>>
>>
>
> Nyquist? are you sure about that?
Yes, thanks for spotting that, I am so used to having nyquist warped
to inifinity that I use them inter
>> It is different for a circuit that isn't a 1 pole RC.
>
>
> no, it's whenever an integrator (1/s in the s universe) is implemented
> numerically with the trapezoid rule. doesn't matter whether it's a C or
> anything else.
RBJ: please show me the derivation for a 2 pole Sallen Key using the
bi-
On 6/22/14 6:01 PM, Urs Heckmann wrote:
On 22.06.2014, at 20:24, robert bristow-johnson
wrote:
On 6/22/14 1:20 PM, Urs Heckmann wrote:
On 22.06.2014, at 19:04, robert bristow-johnson
wrote:
2. Get the computer to crunch numbers by iteratively predicting, evaluating and
refining values
On 22.06.2014, at 20:24, robert bristow-johnson
wrote:
> On 6/22/14 1:20 PM, Urs Heckmann wrote:
>> On 22.06.2014, at 19:04, robert bristow-johnson
>> wrote:
>>
2. Get the computer to crunch numbers by iteratively predicting,
evaluating and refining values using the actual non-lin
On 6/22/14 1:20 PM, Urs Heckmann wrote:
On 22.06.2014, at 19:04, robert bristow-johnson
wrote:
2. Get the computer to crunch numbers by iteratively predicting, evaluating and
refining values using the actual non-linear equations until a solution is found.
perhaps in analysis. i would hate
On 22.06.2014, at 19:04, robert bristow-johnson
wrote:
> i don't think i agree with the following claim, Urs,
>
>> ... but no matter what method of integration we use, we always end up with
>> the same set of equations to solve for the actual step.
>
> different methods of performing numeric
On 6/22/14 7:11 AM, Urs Heckmann wrote:
Dear Robert,
On 22.06.2014, at 04:19, robert bristow-johnson
wrote:
it's possible that this is only a semantic issue.
Thanks for clearing this up. It's indeed a semantic issue (use of the term "nodal
analysis"), which then leads to further misunders
On 22.06.2014, at 16:19, Theo Verelst wrote:
> First: is there such a thing as perfect equivalence between some analog
> system (being linear and time-invariant or not) and a "digital system" such
> that insome way, the output of both for the same input signals is actually
> the same, like in
And once more, still: taking a bunch of difference equations (and some
of those were built up in a respectable way, not as a random opportunist
algorithm), and taking their behavior to be exactly the same as a
sampled analog system requires a little rethinking on behalf of a lot of
people tal
On 6/22/14 2:19 AM, Andrew Simper wrote:
the underlying physics: Kirchoff's current law, Kirchoff's voltage law, and
the volt-amp characteristics of each element *is* applicable to any "lumped
element" circuit, one with any combination of linear or nonlinear elements
or memoryless or non-memoryle
Dear Robert,
On 22.06.2014, at 04:19, robert bristow-johnson
wrote:
> it's possible that this is only a semantic issue.
Thanks for clearing this up. It's indeed a semantic issue (use of the term
"nodal analysis"), which then leads to further misunderstandings.
What we do is, for each node we
Usually all "analog" can be generalized and approxmiated with the
simplest means.
These designs are usually simple to begin with, as less components,
meant more profit.
Sometimes far below "audio-grade" components were used, for instance in
monophonic synths, or feedback paths or similar.
> um, it's a semantic thing that i just wrote about in response to Urs. i
> don't use the term myself, but i am defining "nodal analysis" the way i see
> virtually all other lit doing it. when spice is modeling non-linear
> circuits, it is using Kirchoff's current law on every node, Kirchoff's
>
> the underlying physics: Kirchoff's current law, Kirchoff's voltage law, and
> the volt-amp characteristics of each element *is* applicable to any "lumped
> element" circuit, one with any combination of linear or nonlinear elements
> or memoryless or non-memoryless elements. but the Loop-current
On 6/21/14 10:45 AM, Andrew Simper wrote:
On 20 June 2014 23:37, robert bristow-johnson
wrote:
well, Kirchoff's laws apply to either linear or non-linear. but the
methods we know as "node-voltage" (what i prefer) or "loop-current" do
*not* work with non-linear. these circuits (that we apply t
On 6/21/14 7:21 AM, Urs Heckmann wrote:
On 20.06.2014, at 17:37, robert bristow-johnson
wrote:
On 6/20/14 10:57 AM, Andrew Simper wrote:
On 20 June 2014 17:11, Tim Goetze wrote:
[Andrew Simper]
On 18 June 2014 21:01, Tim Goetze wrote:
I absolutely agree that this looks to be the most
PS—I actually took Rich’s “6ms is unusable” to mean “unacceptable”, which I do
agree with. For instance, when I had a Korg Trinity, I liked the keyboard
action (61 key) very much in general, but I would *never* enable the combi
mode—it was so slow that it was unacceptable to me, even for the far
I agree, Phil, that the “6 msec is not usable” is not a realistic statement.
First, the brain anticipates. Humans are incredible good at throwing things,
for instance. (In a few minutes, I’m heading out to play basketball and drain
some “threes”.) And the brain needs to tell the hand to release
On 6/21/14, 8:09 AM, Rich Breen wrote:
5 msec becomes very noticable on headphones, and above
6 msec is not usable.
Note that the speed of sound in air is roughly 1125 feet/second. So if a
guitar player is more than 7 feet from their amp then they will have
more than 6 msec of latency.
Fo
Hi Rich,
On 22/06/2014 1:09 AM, Rich Breen wrote:
Just as a data point; Been measuring and dealing with converter and
DSP throughput latency in the studio since the first digital machines
in the early '80's;
Out of interest, what is your latency measurement method of choice?
my own experien
Just as a data point; Been measuring and dealing with converter and DSP
throughput latency in the studio since the first digital machines in the early
'80's; my own experience is that anything above 2 or 3 msec of throughput
latency starts to become an issue for professional musicians; 5 msec be
On 20 June 2014 23:37, robert bristow-johnson
wrote:
> well, Kirchoff's laws apply to either linear or non-linear. but the
> methods we know as "node-voltage" (what i prefer) or "loop-current" do
> *not* work with non-linear. these circuits (that we apply the node-voltage
> method to) have depe
On 20.06.2014, at 17:37, robert bristow-johnson
wrote:
> On 6/20/14 10:57 AM, Andrew Simper wrote:
>> On 20 June 2014 17:11, Tim Goetze wrote:
>>
>>> [Andrew Simper]
On 18 June 2014 21:01, Tim Goetze wrote:
> I absolutely agree that this looks to be the most promising approach
>
On 6/20/14 10:57 AM, Andrew Simper wrote:
On 20 June 2014 17:11, Tim Goetze wrote:
[Andrew Simper]
On 18 June 2014 21:01, Tim Goetze wrote:
I absolutely agree that this looks to be the most promising approach
in terms of realism. However, the last time I looked into this, the
computational
On 20 June 2014 17:11, Tim Goetze wrote:
> [Andrew Simper]
> >On 18 June 2014 21:01, Tim Goetze wrote:
> >> I absolutely agree that this looks to be the most promising approach
> >> in terms of realism. However, the last time I looked into this, the
> >> computational cost seemed a good deal to
On 20.06.2014, at 11:11, Tim Goetze wrote:
> I
> mistakenly thought you were proposing nodal analysis including also
> the nonlinear aspects of the circuit including valves and output
> transformer (which without being too familiar with the method I
> believe to lead to a system of equations th
[Andrew Simper]
>On 18 June 2014 21:01, Tim Goetze wrote:
>> I absolutely agree that this looks to be the most promising approach
>> in terms of realism. However, the last time I looked into this, the
>> computational cost seemed a good deal too high for a realtime
>> implementation sharing a CPU
Getting by with 25 brings down your risk. The investment needed for building
software is much lower than that for custom hardware. To get started software
therefore makes more sense. Once you've got it to sound good bring down delay.
Sent from my Samsung Corby
--
dupswapdrop -- the music-dsp mai
On 19/06/2014 7:09 PM, Rohit Agarwal wrote:
Enlighten me, does that mean faster tempo or is 10% too much delay for
that?
I think that this conversation is at risk of going off the rails. Make
sure that you're asking the right question.
There are a number of different ways that delays can imp
Enlighten me, does that mean faster tempo or is 10% too much delay for
that?
From:"Sampo Syreeni"
Sent:"A discussion list for music-related DSP"
Date:Thu, June 19, 2014 2:04 pm
Subject:Re: [music-dsp] Simulating Valv
On 2014-06-19, Rohit Agarwal wrote:
I'm surprised by that statement quite honestly. At a tempo of 200 bpm,
this latency would be roughly 10% of the beat interval which seems to
me quite small.
Then you obviously don't know techno. ;)
--
Sampo Syreeni, aka decoy - de...@iki.fi, http://decoy.ik
SP"
Date:Thu, June 19, 2014 1:35 pm
Subject:Re: [music-dsp] Simulating Valve Amps
> On 19/06/2014 4:52 PM, Rohit Agarwal wrote:
>> In terms of computational complexity, most of the complexity is
in
>> modelling, tuning the parameters to fit data. However, once
you're
ed to avoid using it as a digital piano).
>
>
> From:"Ross Bencina"
>
> Sent:"A discussion list for music-related DSP"
>
>
> Date:Thu, June 19, 2014 11:59 am
>
> Subject:Re: [music-dsp] Simu
On 19/06/2014 4:52 PM, Rohit Agarwal wrote:
In terms of computational complexity, most of the complexity is in
modelling, tuning the parameters to fit data. However, once you're done
with this offline task, running the result should not be that heavy. That
process should be real-time on new CPUs.
t
the buffering which should get you down to 25 ms.
From:"Ross Bencina"
Sent:"A discussion list for music-related DSP"
Date:Thu, June 19, 2014 11:59 am
Subject:Re: [music-dsp] Simulating Valve Amps
> Hi Sampo,
>
Hi Sampo,
On 19/06/2014 4:06 PM, Sampo Syreeni wrote:
On 2014-06-19, Ross Bencina wrote:
There is a segment of the market that values accurate models--at any
computational cost.
Keep in mind that this was a response to your claim that "nobody's going
to pay you." I'm not taking a position o
On 2014-06-19, Ross Bencina wrote:
There is a segment of the market that values accurate models--at any
computational cost.
Then, can you do that at low latency, so that your model is also
"playable"? That's of course the next frontier. And no, there's no
shortcut there: those giga-computati
On 19/06/2014 8:49 AM, Sampo Syreeni wrote:
Obviously you *can* painstakingly model even that, and achieve
perfect results, but there's always the cost constraint: nobody's
going to pay you for the years of lab time it takes to characterize
such circuits perfectly, not to mention that sinking mul
On 2014-06-18, STEFFAN DIEDRICHSEN wrote:
Actually, it’s not rocket science to model a baxandall or those
Treble/Mid/bass networks. A straight forward approach is modified
nodal analysis, which gives you a model, that preserves the passivity
of the filter network.
Obviously. If it's passive,
I came across one of my old posts on this subject (see below).
I still think that Eric K. Pritchard's patents contain almost every
important detail to know about this subject. Especially, his later
work concerning "Fat Emulation" (i.e., sound enhancements caused by
various inter-modulation distort
Fender once patented a relatively efficient tone stack simulation method:
"Simulated tone stack for electric guitar"
by Curtis , et al.
US patent #6,222,110
www.uspto.gov
On Wed, June 18, 2014 4:01 pm, Tim Goetze wrote:
> [Andrew Simper]
>
>> On 18 June 2014 18:26, Tim Goetze wrote:
>>
>>> ...
Once more, you'd have to think about this problem as to include a
curtain test (within reason, I mean just to make the point) where you
take the optimal example tube amp, place the mic in front of it, put
that on the PA or monitoring in another room (or in the same room, to
let the guitar fee
ls?
>> :)
>>
>> M.
>>
>>> -Messaggio originale-
>>> Da: music-dsp-boun...@music.columbia.edu [mailto:music-dsp-
>>> boun...@music.columbia.edu] Per conto di Nigel Redmon
>>> Inviato: mercoledì 18 giugno 2014 08:22
>>> A: A disc
igel Redmon
>> Inviato: mercoledì 18 giugno 2014 08:22
>> A: A discussion list for music-related DSP
>> Oggetto: Re: [music-dsp] Simulating Valve Amps
>>
>> Well, some people think it’s close enough for rock n rock (amp sims),
> others
>> don’t. It’s the same
Of course, high gain amps have from four to six gain stages (and the stages may
have attenuation). I’m simplifying by putting all the gain in one stage, but
the point is that when you’re cranked on one of these amps, you can count on
being locked into the hard-clip region of the curve, and the s
On 18 June 2014 21:01, Tim Goetze wrote:
>
> I absolutely agree that this looks to be the most promising approach
> in terms of realism. However, the last time I looked into this, the
> computational cost seemed a good deal too high for a realtime
> implementation sharing a CPU with other tasks.
[Andrew Simper]
>On 18 June 2014 18:26, Tim Goetze wrote:
>> ... Thanks to
>> the work of Yeh, I personally consider the tonestack a solved problem,
>> or at least one of least concern for the time being.
>
>A linear tonestack has been a solved problem way before Yeh wrote any
>papers. Also I wou
On 18 June 2014 18:26, Tim Goetze wrote:
>
> ... Thanks to
> the work of Yeh, I personally consider the tonestack a solved problem,
> or at least one of least concern for the time being.
>
> Cheers,
> Tim
A linear tonestack has been a solved problem way before Yeh wrote any
papers. Also I would
[STEFFAN DIEDRICHSEN]
>Actually, it's not rocket science to model a baxandall or those
>Treble/Mid/bass networks. A straight forward approach is modified
>nodal analysis, which gives you a model, that preserves the passivity
>of the filter network.
Perhaps I was being too vague; in any case, I wa
On 18 June 2014 16:15, STEFFAN DIEDRICHSEN wrote:
> Actually, it’s not rocket science to model a baxandall or those
> Treble/Mid/bass networks. A straight forward approach is modified nodal
> analysis, which gives you a model, that preserves the passivity of the
> filter network.
>
> Steffan
>
>
On 18 Jun 2014, at 01:07, robert bristow-johnson
wrote:
> well, we gotta think sorta like the string theorists. we gotta imagine how
> to seamlessly glue together two ostensibly incompatible systems. like how do
> we crossfade from the low-gain behavior (the "warm tube sound") to the
> beh
Actually, it’s not rocket science to model a baxandall or those Treble/Mid/bass
networks. A straight forward approach is modified nodal analysis, which gives
you a model, that preserves the passivity of the filter network.
Steffan
On 18 Jun 2014, at 10:01, Tim Goetze wrote:
> [Sampo Syree
[Sampo Syreeni]
> From what (very little!) I know of hardcore analog simulations, I'd say
> that is part of a more general and much nastier problem. That's the
> interaction
> one: whereas digital signal graphs have a definite direction of signal flow,
> there's no such thing on the analog side n
That’s a wild theory. ;-)
E.g. A Leslie 122 amp has a rather small power supply transformer, which has to
deliver B+ and heater voltage. The output transformer is about 1.5 times the
size of the power tranny.
If it comes to output transformers, the distortion caused by them is rather
mild. It i
I had the pleasure to work on a Soldano designed amp (Yamaha T-100). Once I got
it fixed (2 resistors burnt off), it was a hell of an amp. What makes me
wonder, that compared to a Marshall amp, you could get a super overdriven sound
with very low noise. The marshall basically spit out noise on t
Well, some people think it’s close enough for rock n rock (amp sims), others
don’t. It’s the same with analog synths and virtual analog. But there’s also
the comfort of tube amps, and there’s the comfort of the limited sound palette
of using the amp that you know and love. Amp sims are really ab
On 6/17/14 8:24 PM, Nigel Redmon wrote:
(Thinking outside the nest…)
(...maybe that means opening up the LPF as the gain knob setting is reduced)
Yes
And good discussion elsewhere in there, thanks Robert.
yer welcome, i guess.
you may be thinking outside the nest; i'm just thinking out lou
1 - 100 of 124 matches
Mail list logo
