Helix 3.5 New Cab Engine is Awesome! Fractal needs to catch up!

FractalAudio said:
FWIW we've been working on something like this for the past six months or so. We have several robots that we use for automated IR capture, custom control software, etc., etc.

I didn't want to spill the beans this early but...

Your patience will be rewarded.
Click to expand...
This is the best news I’ve heard since hearing “I’m pregnant” 16 years ago! Oh god how I’m waiting for this so I can stop shooting FAS models into my DAW using Two Notes WOS.
 
GreatGreen said:
For front panel editing, there's really no need for a fancy UI with a picture of a mic and speaker to get the same functionality of the Helix. What you'd need for the Axe-Fx would be a list of built-in search filters (mic, speaker model, number of speakers in the cab, cab brand, etc) to narrow down from the list of displayed IR's already in the Axe-Fx and that would be enough.

For Axe Edit, I like the idea of a tagging system where you can filter by search phrases. This kind of thing currently can't really be done in Axe Edit because of how the search function interprets the "space" character. What I mean is that if I'm looking for IR's in Axe Edit and type "2x12" and hit enter, I'll get a list of 2x12's. Good deal. And if I type "57" and hit enter, I'll get a list of all IR's that contain "57" in the name. Fine. However, if I type "2x12 57" and hit enter, the search results come up blank because the search function is looking only for that specific string of characters, which no IRs contain.

It would be more useful if the "space" character wasn't viewed as a part of the search string, but was instead viewed as a separator for search terms in an AND/OR format. Default could be the more narrow AND format so if you type "2x12 57" you'd get a list of IR's containing both "2x12" and "57" terms, but if you typed "2x12 or 57" you'd get a list of everything that contained either one of those terms.
Click to expand...
https://forum.fractalaudio.com/thre...earch-content-e-g-amp-effect-cab-name.139810/
 
FractalAudio said:
FWIW we've been working on something like this for the past six months or so. We have several robots that we use for automated IR capture, custom control software, etc., etc.

I didn't want to spill the beans this early but...

Your patience will be rewarded.
Click to expand...
Yeah Cliff!!
 
ElectricPhase said:
This is one big can of worms.

Yes, picking IRs from a shorter list and choosing adjustments consistently using mic type and position would be more intuitive, but everyone would have to do the same captures with the same methods. I'd think this would be rather discouraging to third party IR vendors.

L6 solved a longstanding problem with their cabs, and did it well. I'm not convinced that makes it the bandwagon to jump on for everyone.
Click to expand...
I don't know that IR makers would have to do things exactly the same.

Consider metadata for on- v. off-axis position. Store it as a value between 0.0-1.0 or -1.0 to 1.0. IR makers can choose to capture as many or as few positions along that range as they wish.
 
notalemming said:
Yeah, I was really wondering if this would work on an Axe III MKI & if not, could it be implemented into CabLab.
Click to expand...
Since the Cab block editor in *Edit is basically Cab-Lab Lite, it should be a safe bet that, if Cab-Lab gets updated to work with whatever is coming, that the Cab block editor will also be updated to remain a "Lite" version.
 
Greg Ferguson said:
Since the Cab block editor in *Edit is basically Cab-Lab Lite, it should be a safe bet that, if Cab-Lab gets updated to work with whatever is coming, that the Cab block editor will also be updated to remain a "Lite" version.
Click to expand...
That may be but my understanding of this is it takes a whole lot of IRs to make smooth transitions for mic movement, even for 1 cab, 1 speaker, 1 mic, so there may not be enough memory on the MKI Axes to handle all the needed IRs. I hope there is but, of course, Cliff is the only one who can truly answer that.
 
notalemming said:
That may be but my understanding of this is it takes a whole lot of IRs to make smooth transitions for mic movement, even for 1 cab, 1 speaker, 1 mic, so there may not be enough memory on the MKI Axes to handle all the needed IRs. I hope there is but, of course, Cliff is the only one who can truly answer that.
Click to expand...
If I was doing it and it was *Edit based, there'd be a base IR, then diffs based on it to reduce the size of the additional files, all stored as a bundle of some sort, possibly even compressed. The editor would apply the necessary diff to the IR and that would be written to the unit.

If it's handled inside the unit itself, the same idea would apply, there'd be a base IR and diffs for subsequent IRs for the other variables, then the resulting IR would be created, probably as everything was copied to memory. Doing that during a preset or scene change would slow the switching so pre-computing the IR would be smart.

There'd need to be some additional information stored alongside the base IR, which implies that there'd have to be some adjustment of the Cab banks, possibly similar to what happened when a bank was reallocated and slots reduced for the FullRes IRs.

Cliff's announcement gives no idea of a timeline for this capability. It could be implemented in the current generation hardware, or it could be the next generation whenever that comes along.
 
I thought I had read this being hinted at way before Cliff spilled the beans here, so maybe others got inspired by Fractal...? ;)

(Yes, I'm aware that, for example, some plugins have had this for a while.)
 
Last edited:
I so welcome any movement on this front. I capture IRs now from several different movable mic plugins, and anything like that from FAS would be absolutely a dream come true to me. Thank you as always for continuing to make the best even better.
 
High Quality Im Shocked GIF
 
Couple different issues here:

Spiffy UX with mic positions - this sort of thing only really works if you've got the IRs to back up the combinatorial explosion of all the parameters. This sounds cool and Cliff mentioned something cool is in the works. Doing this generically with any random IR would not likely be able to produce results that would make much sense - although metadata could be used to provide some info that an interesting UX could be built on.

IR metadata support and usage for IR selection UX - there's a lot of possibilities here. It wouldn't be too hard to come up with a list of tags and publish this information - a defacto standard would suffice - IR vendor, type (cab/instrument) and mix/single, mic vendor/models/positions, speaker vendors/models/positions, cabinet vendors/model/config, far/near field, instrument vendor/model, etc. It also wouldn't be too hard to write a batch tool to auto generate the metadata for most existing IRs based on file names - just some regular expressions and abbreviation mappings would be required.

Metadata support in WAV files is somewhat sketchy. To avoid dependencies on embedded metadata support and to enable vendors to easily distribute metadata updates for their libraries (and let users customize the metadata with a text editor), it would make a lot of sense to expose the metadata via XML/Json/Yaml files. When IRs are imported, the directory could be scanned for files with a well known file extension to retrieve metadata.

In the midst of all this, it would be nice to add support for IR IDs/hashes to identify which IR to load rather a specific slot - this greatly simplifies preset sharing. There's already a wish list item for this.
 
You must log in or register to reply here.
Back
Top Bottom