IK Multimedia TONEX

[Chocol8]

Well, depending on the captured amp, the file might be altered quite dramatically, so the first transient isn't as clear anymore - and that'd be the only thing it could use as an anchor for autotrimming. Capturing a noisy amp might add to the issue.

Fwiw, I have been running into this issue before, when shooting some IRs using Logic's Impulse Response Utility quite some years back. The resulting IRs had some silence in the beginning ocassionally (I was capturing some kinda wild stuff which involved running the signal through some DAW processing). Didn't happen again when I did a similar thing not that long ago, but I'm still curious.

Possibly best to just give it a try.

The beginning of the first transient should be pretty discernible and easy enough for software to automatically align to. It doesn't matter how distorted the signal gets, just when it starts to exceed the noise floor.

 

[EOengineer]

This whole magic trick is basically a per sample diffing engine comparing clean and processed files, isn’t it? We can assume the alignment is inherent or the accuracy of the models could be WAY off.

 

[hunter]

it’s probably more important to have a constant/steady latency than a low one during capturing. I guess an Computer/interface setup set to the lowest possible latency might be more prone to hickups, than when it’s deliberately set a little higher value- pure speculation though.

 

[[Nathan]]

So, any takers? How is that handled?

The training file is a certain length
You pump it into your amp then back out via cab/mic or loadbox back into your interface
It auto aligns the training file to the fixed length of recording

Latency for this doesnt come into the equation at all, its just auto aligning the files

 

[Sascha Franck]

Latency for this doesnt come into the equation at all, its just auto aligning the files

That makes no sense. In case the return file is longer than the training file, it needs to be trimmed somehow. Auto aligning would only work in case the files were of the same length, which they aren't. So the returning file must be trimmed at some point.

 

[[Nathan]]

That makes no sense. In case the return file is longer than the training file, it needs to be trimmed somehow. Auto aligning would only work in case the files were of the same length, which they aren't. So the returning file must be trimmed at some point.

Yes, all happening automatically.

 

[Sascha Franck]

Yes, all happening automatically.

So how does the Tonex Modeler app decide on introduced latency?

 

[[Nathan]]

So how does the Tonex Modeler app decide on introduced latency?

Are you talking about the capturing process? It’s just comparing file A to file B. Before the comparison it would auto align and match the length.

This is all kind of obvious stuff, are you having some other issue related to latency?

 

[Sascha Franck]

Are you talking about the capturing process? It’s just comparing file A to file B. Before the comparison it would auto align and match the length.

Again: How would it know how to auto align before comparing the files and doing the math?

 

[EOengineer]

Again: How would it know how to auto align before comparing the files and doing the math?

I’m not sure if I’m understanding the question, but the training file starts with a series of clicks. That’s at the very front of the capture test file. As another user pointed out, those sharp clicks are alignment guides that the software is using to align the source audio and processed result before it analyses the differences between the files and builds the model.

 

[Sascha Franck]

I’m not sure if I’m understanding the question, but the training file starts with a series of clicks. That’s at the very front of the capture test file. As another user pointed out, those sharp clicks are alignment guides that the software is using to align the source audio and processed result before it analyses the differences between the files and builds the model.

Ah, ok, I missed the sharp click part of things. That does explain it. Thanks!

 

[[Nathan]]

Again: How would it know how to auto align before comparing the files and doing the math?

They wrote an algo/program to figure it out. Does the actual underlying code and process make any difference? It’s just time aligning audio.

This kind of question would only be fruitful if there was a problem with the process/results. If it’s all working as expected then well done.

 

[Sascha Franck]

Still, as a rather academic follow up question: In case I was capturing some incredibly distorted, untight amp, possibly even adding some noise all the time, could the auto alignment fail and misinterpret things? Even if it would just be by a mere handful of samples, that could possibly throw the measuring procedure and perhaps cause some inaccuracies. Could that be a thing?

 

[Orvillain]

First click is probably explicitly for alignment.

Source sample position compared to output sample position.
If there is a negative diff, pad the front with zeros until they match, crop off the end.
If there is a positive diff, crop the front until they match, pad the end with zeros.

Instead of cropping, you could also wrap if you wanted, and if it wasn't going to ruin whatever you were going to do with the audio later.

 

[Sascha Franck]

First click is probably explicitly for alignment.

I get that. But I'm still wondering (see last post) whether this could be the source of some inaccuracies. I mean, if you really, really smash the input file (kinda like beyond recognition), the alignment could possibly be less exact.

 

[[Nathan]]

I get that. But I'm still wondering (see last post) whether this could be the source of some inaccuracies. I mean, if you really, really smash the input file (kinda like beyond recognition), the alignment could possibly be less exact.

 

[Sascha Franck]

You know, I've never been much of a fan of stupid memes. But you're easily topping it here. Thanks for confirming some things.

 

[MirrorProfiles]

I get that. But I'm still wondering (see last post) whether this could be the source of some inaccuracies. I mean, if you really, really smash the input file (kinda like beyond recognition), the alignment could possibly be less exact.

why are you worrying about problems that don’t exist? No one has ever mentioned issues with latency or the blips being misaligned. It’s already designed to capture fuzz pedals and highly distorted amps and the alignment blips are the very first thing you hear when reamping.

It has nothing to do with Logic’s Impulse Response Utility, with making IR’s there may be situations where you specifically do not want it to automatically align the resulting IR. When making an amp model, the requirements are totally different and it’s already designed with that in mind.

 

[Sascha Franck]

with making IR’s there may be situations where you specifically do not want it to automatically align the resulting IR.

IMO that isn't true. You want the sweep (or whatever you've used) to align perfectly with the recorded file, even if the source impulse (sweep, gunshot, etc) is completely masked by the recording. Sure, you also want to capture the timing properties of whatever you capture, but for that to come out accurately, you have to make sure the returning file is lined up properly (as in only containing the offset of the captured thing but no additional latency).

 

[[Nathan]]

You know, I've never been much of a fan of stupid memes. But you're easily topping it here. Thanks for confirming some things.

That’s where you’re wrong, apt response to apt questions