Lysander
Rock Star
- Messages
- 2,525
tbf, the Helix model of the B7K is pretty great
A bassist acquaintance of mine mentioned several times the model in his HX Stomp sounds just as good as the pedal.
tbf, the Helix model of the B7K is pretty great
The latency probably has a lot to do with their use of Linux. It can be decreased with more effort but ultimately you have an OS with buffers.
The latency probably has a lot to do with their use of Linux. It can be decreased with more effort but ultimately you have an OS with buffers.
Not surprising given the Mod Duo DNA.
tbf, the Helix model of the B7K is pretty great
They just gotta hit the turbo button and it'll double the giggawattzThis isn’t complete nonsense, but I imagine with a minimum of effort you could get it the rest of the way there.
Well, today is day 2 of its release, in the upcoming months they will have many FW updates, i trust me, this will be a guitar product also.
6ms for the loop seems a bit much?
Quite normal. 3ms for one ADDA cycle isn't particularly low but not particularly high, either.
Latency:
empty chain: 3ms
1 NAM profile: 3ms
2 NAM profiles: 3.1 -3.2 ms
2 NAM profiles + 1 NAM profile in parallel: 3.1 - 3.2 ms
FX loop engaged: 6ms
And the null test results to see how close the Anagram is to the NAM software - I'm guessing a separate video :)
Stick a Digital device in that Loop and you will easily hit around ~10ms .... not horrendous but far from great.
..... run multiple NAM instances using Kushview’s Element .....
I don't know. At that price point, you might as well get a powerful notebook + a good audio interface + a MIDI controller, and easily run multiple NAM instances using Kushview’s Element. Besides, all the bundled digital Darkglass slop does little to make the unit more appealing.
Not familiar with ^this^.
It's a plugin host. So you can run any amount of any quality NAM captures.
This is why I am 100% in the modeling camp and 0% in profiling/capture. Well, that and because Kemper's "liquid profile" effort notwithstanding, I can't actually use an amp tone stack with them. Post EQ is fine but it's a not a substitute for a tone stack, even (perhaps especially) when not trying to emulate a specific tone.NAM itself is free, it will be a hardware company that leverages it to “upset the market”. The biggest issue I see right now is running it at high quality requires a lot of computational resources, so getting it 1:1 in hardware that is at a price point people will buy is the issue. Honestly the more I see of profiles/capturing the happier I am to not live in the world of trying to emulate a specific amp or tone. Talk about a race to nowhere.
That summarizes it for me as well. They can sound great. But I find them unpleasant to work with, like trying to fix things in post rather than at the amp.As for biases, I'll acknowledge captures can sound good. I just hate working with them.
Well I have a few pieces of gear I want replicated as accurate as possible so that I can have that tone and not haul stuff around, risk accidents / theft etc.But that's just me. A guy I've been talking/playing music with for decades loves his Kemper and might buy my Tonex. He's all capture, no modeling.
Sure, I get that. We all have different preferences and desires.Well I have a few pieces of gear I want replicated as accurate as possible so that I can have that tone and not haul stuff around, risk accidents / theft etc.
My background in tech, including in engineering management at a pretty big tech firm, leads me to conclude otherwise. There are a lot of potential complications and a lot of "it depends" involved in adding that support. I could see a capture device manufacturer deciding to support any format they can. The overall software philosophy is probably fairly similar, from I/O to interface and beyond. I think for a modeling company to do it is to introduce a significant parallel development roadmap that would leech resources away from their core product development. This would, 100% guaranteed, not be a one-and-done, "there, I fixed it" kind of thing. Integration of proprietary code with an open source spec that is undergoing active development - the directions and timelines for which the manufacturer by definition cannot control - is a significant undertaking. At the same staffing, you'd have to permanently pull people off of improving the modeling and adding new models in order to do it.I like both modelling & profiling and I think any vendor adding NAM support to their platform can only benefit from it in the long run.
Can we not bring background in tech / professional path into the conversation? Just feels like an ego thing when posts like that pop up; at the end of the day you never know who's at the other end of the conversation.My background in tech, including in engineering management at a pretty big tech firm, leads me to conclude otherwise. There are a lot of potential complications and a lot of "it depends" involved in adding that support. I could see a capture device manufacturer deciding to support any format they can. The overall software philosophy is probably fairly similar, from I/O to interface and beyond. I think for a modeling company to do it is to introduce a significant parallel development roadmap that would leech resources away from their core product development. This would, 100% guaranteed, not be a one-and-done, "there, I fixed it" kind of thing. Integration of proprietary code with an open source spec that is undergoing active development - the directions and timelines for which the manufacturer by definition cannot control - is a significant undertaking. At the same staffing, you'd have to permanently pull people off of improving the modeling and adding new models in order to do it.
It's not ego. I appreciate it when people who have relevant experience to what they're talking about identify themselves. Could they be lying? Sure. But that pretty much always reveals itself. I'm trying to establish a basis for assertions about development resources associated with this kind of integration. People gloss over that, and it matters. The standard existing and being open source \doesn't make it drop-in. Nothing is drop-in to a proprietary product - especially when both the product and the open source standard remain in active development.Can we not bring background in tech / professional path into the conversation? Just feels like an ego thing when posts like that pop up; at the end of the day you never know who's at the other end of the conversation.
Yes, but the integration into their proprietary code is not done. And it's a significant effort. And NAM is under active development. What it takes to implement it will absolutely change. To adopt it means a perpetual development roadmap. Integration of open source standards always does. It has to.As far as NAM profiling's concerned, the tech's already there. Vendors that want to support it need to bear the expense of porting it across but still without the expense of a full-on R&D effort - legwork's already done. It's mostly about cost & setting boundaries so it stays manageable & can still squeeze a margin / profit.
I have indeed poked around at the repo. I was speaking specifically to high end modelers - Fractal, Line 6, TMP. This would, IMO, not at all be a good choice for them. For an existing capture/profile-based device? That case seems stronger. But it's a whole new parallel development path for makers of modelers. I will be surprised if they adopt it. They'll make their choices regardless of what threads like this say.There's nothing stopping vendor X of setting boundaries on how large (number of paramenters in the neural profile) can be & the NAM repo already has several pre-canned architectures which favor accuracy or sacrifice some of it to allow slower machines to run it.