Enjoy the benefits of a premium membership!
Upgrade Account
-
TalkBass has been independent since 1998. Add your voice.
Create a free account to reply to discussions, view embedded media, and browse with fewer display ads.
Join free Log in
Want zero display ads or expanded classifieds tools? Compare plans.
Darkglass Anagram Multi FX Announced
- Thread starter Elmstreet
- Start date
I have mine setup for some mid amounts of overdrive, rather placing the effects loop at the beginning of my chain and then adjusting g the blend to give me a desired amount of tube.
Has anyone loaded up a preset with parallel path and a full compliment of "kitchen sink" blocks (amps, drives, comp, IR, chorus, etc.) to see where that latency spec lands? If it were to remain at 2ms or less, that would be impressive. Can someone report on this, out of curiosity?
I can give this a shot. I pulled up a few of the presets with NAM models and it initially looked like a similar latency to my block-less chain but can double check.
I have no way to measure the exact latency, but I haven't noticed any issues with parallel paths including effects loop. So far it seems very good.
I also ran into the same issue (which was different from the other macro issue). Super cool that they're trying to get the fix out before the weekend.
I was pleasantly surprised at how good the tuner is on this thing. Really solid piece of work there!
I imagine Darkglass did when they were testing the unit?
They certainly know the answer, but as with anything that's perceived as a negative, their marketing department is only publishing vague or best-case answers to the question of total latency. I don't own an Anagram (yet) but would be willing to bet that even under heavy loads the amount of latency will be inconsequential to the needs of a bassist using one in real world scenarios.
One of the first things I did was try to more or less recreate what I've got on my big board, which left maybe 2-3 blocks unused? No NAM, but I can say that the device didn't break a sweat in the face of attempts to Dunning-Krueger my way through the initial (very short) learning curve.
Here you go...from the owner's manual:
The operative term " empty signal chain ". If latency increases with a "non-empty" signal chain, that would be good to know IMHO. If I were to create a preset that approached max cpu usage, I'd want to know how much latency is added ( IOW max latency ). This tends to vary from block to block depending on the specific process. Some are heavy on processor usage, and others not so much.
FWIW, I don't recall this specific discussion about latency as being assumed to be a negative, nor am I the least bit interested in trying to establish some sort of "gotcha" specification issue. I just want to know because I'm curious. Where it might become an issue has nothing to do with any single piece of gear, though there are scenarios where using a digital pedal in conjunction with 3 or 4 more digital I/O stages (before sound is produced from a physical driver) might approach discernible latency. In the case of pitch-shifted down algorithms, latency is a known issue with a lot of (if not most) digital products.
So, as a probable/likely Anagram owner, please don't read any more into this, at least regarding my posts on this. I geek out on tech spec info sometimes, that's all.
Last edited:
Tuner functions great! I have 3 small nitpicks with the tuner function:
1) The little cents reading in the upper left corner is really small and very hard to read. The tuner seems very accurate, and it's cool that they give us the cents display. I'd personally prefer a strobe display option, as I've always found the strobe mode on my HX Stomp to be faster to get tuned up, at least from a visual standpoint. Far from a deal breaker, and perhaps they'll add some other tuner display options down the road. I'm also far from used to using the Anagram tuner, and it is absolutely good enough to replace any standalone pedal board tuner IMO.
2) When the tuner is activated, I don't care for the mute/unmute option being on a footswitch (not to be confused with tuner screen on/off). I'd rather it be a touch toggle on the tuner screen. My instinct when I'm done using the tuner is to hit any footswitch to turn it off. Instead you must hit the left footswitch. Which leads me to nitpick 3...
3) Related to the tuner mode is the tap tempo function. You must have foresight for when they want to use the tap tempo function mid-song, and therefore toggle the tuner to unmuted (see nitpick 2) before the song starts. If you forget to do this, then mid song, it's too late! Because while you're playing and you decide you need to use tap tempo, you have to enable the tuner, quickly hit the mute/unmute footswitch so your signal comes back, and then do tap tempo. I suppose they could add a toggle for the effects blocks that can utilize tap tempo to instruct the unit on how you want to get into tap tempo mode (tuner muted or unmuted). I feel like there are a lot of possibilities to solve this problem, and perhaps they'll integrate something logical and consistent. For my use case, I generally only use delay as a small enhancement for solos, so the tempo I want for the repeats can be anything.
Regarding the delays, it's a little funny to me that on all 3 current available delay blocks, the time control (when the subdivision is set to "Tempo ctl off") consists of a Range, and then a Time control that ranges from "min" to 10. In other words, no real clear indication of a BPM or millisecond value. Maybe I just suck at math, but that makes my brain hurt.
From these numbers we can assume that this is the latency it takes for a signal to go from an analog input outside of the Anagram, cross the AD converter and then come out the DA converter on the other side. The loop requires the signal to go through that process twice and since the value doubles it seems to fall right in line with what would be expected. They're not likely reporting the latency incurred by the unit's operating system, and they're certainly not reporting the processing times needed for any DSP the end user adds into their signal chain. Anything that requires real time tracking such as octaves, pitch shifting, etc. will likely require the most DSP and thus cause the greatest increase in latency. Anything that occurs as a result of a signal input and produces a sound after it such as reverb and delay, will likely require the least DSP and thus cause the lowest increase in latency. I would stack up a bunch of pitch shifting blocks and see what the results are. I'm guessing the number won't hit 4ms even if all of the available blocks are filled with high-DSP processes as long as the loop isn't used. I'll also reiterate that this level of latency is inconsequential to real world playing scenarios.
Of course. My concern isn't with the unit by itself, in isolation, thus I feel it's gone off-topic a bit.
I just want to try to figure out, worst case scenario, what max latency of an entire CHAIN of digital items would be and what Anagram could contribute, for example:
- digital wireless transmitter: 2-4ms
- Anagram: 1.3ms
- digital multi-fx in send/return loop of Anagram: 1.3ms + 2-4ms (multi-fx in loop)
- digital mixer via digital snake: 2.5ms
- wireless digital IEM or powered wedge with onboard DSP: 2-4ms
If total latency from all of this is 10ms or less, then probably not an issue. But depending on the gear used, it could get up into the 12-15ms range, thus causing me to consider where I might want to either subtract an item from the chain or be more mindful about the latency specs of certain individual items (like the wireless transmitter, IEM, or powered speaker). In this scenario, the primary multi-fx ( Anagram ) would be the LAST thing eliminated from the chain, which is to say that it would NOT be eliminated for reasons of latency.
Apologies if I'm pissing against the wind here, or if anyone feels this line of thinking is contentious. I'm just looking for spec info.
How about those bass tones though am I right!? 
Not at all. The cumulative effect of latency across an entire system of devices and potentially considering the speed of sound at significant distances on large stages if IEM monitoring isn't in use could indeed be a concern. To your point though, the tiny bit of latency from any single piece in the chain is likely not a deal breaker on its own.
