• SONAR
  • Interesting TASCAM News from AES (p.5)
2014/10/10 22:53:17
vintagevibe
Anderton
vintagevibe
Are these that same in-house developers that destroyed Gigastudio?



No. You might want to ask Garritan, who bought the technology, why they haven't continued to develop Gigastudio.
 
IMO in-house drivers from Tascam is a serious liability.

 
Seriously? Having third party companies thousands of miles away that split their resources among multiple clients is less of liability than hiring a team of in-house software developers dedicated solely to a company's products?
 
I'm not passing judgement on the new drivers, I haven't used them yet. I'm pointing out that TASCAM is bringing development in-house. Most people realize that has far more potential for timely updates than relying on outside companies and working around their schedules. It also means these drivers will be tested extensively with Sonar, which not all companies do.




In-house is only as good as the house.  Tascam has a great reputation for hardware and a terrible reputation for software.  They're simply not a software company and good drivers are not easy to write.  So a hardware company is building a new software development team from scratch.  It reminds me of MOTU and their Windows version of DP.  It will probably work someday but I wouldn't touch it until it's been out for several years and is proven to be solid.  And that's from a company with a good reputation for software.  Tascam is a different story.

2014/10/10 23:15:10
Anderton
Whatever knowledge you have of TASCAM's inner workings are at odds with what I've seen over the past 1.5 years since the acquisition occurred. They have been accumulating considerable software and DSD expertise as well as other expertise I can't discuss. It's not like they woke up yesterday and said "Hey, let's hire some kids off the street, and write drivers!" They know drivers are difficult to write. That's why they had been using third-party companies to write them. This is part of a long-term strategy.
 
Look at what happened with Cakewalk since the acquisition. Compare how X3 has been handled compared to X2. Similar changes are occurring at TASCAM. 
 
I said I wasn't going to pass judgement on the drivers until I had a chance to evaluate them. However, I am comfortable stating that bringing driver software development in-house is a positive move. If you think TASCAM has a terrible record with software, it seems odd that you would automatically assume that pursuing a different direction in an effort to improve that record will not provide at least some degree of improvement.
2014/10/10 23:56:49
gswitz
Master Magic Maker
 It's not like they woke up yesterday and said "Hey, let's hire some kids off the street, and write drivers!" 

.
btw, sometimes it's the kids off the street who you want!! I'm a software guy and I realize that the right guy for the last problem isn't always the right guy for the next problem. That said, I totally think it's a great idea to have in-house software developers.
 
And, I used my Tascam 2488 with my RME UCX tonight to make a 16 track recording. It was a great time.
 
I much prefer my Tascam 2488 to the M-Audio devices I've had. And the Line 6. The Tascam has had surprising staying power.
2014/10/11 00:26:58
thomasabarnes
I've been checking out the Tascam UH 7000. There are impressive reviews on Amazon, Sweetwater, and Youtube, especially about the preamps and AD/DA converters in the unit. I think I'm sold on getting one (if only to use it as a standalone preamp), but one or two owner reviews say that the drivers are somewhat lacking in low latency performance. I checked the UH 7000 download page and there has been an update to the drivers since the unit was firist released, but I don't know what's beeing said about them improvement wise. Still with this news (of writing in house drivers) and because the preamps are so impressive, as I watched a review of the unit on Youtube, I think I'm gonna get one. 
 
If the in house driver team can write some drivers that will get the unit to perform at 8.2 ms roundtrip latency or lower, I think I can live with that performance.
 
I went to the Tascam site earlier today and read the news section and saw that Tascam announced the TASCAM US-16x08 audio interface today at the AES show in LA.
 
I'm gonna check in there tomorrow also to see if there are any more audio interface announcements like some big brother to the UH 7000, as the preamps on the UH 7000 are better (specs wise) than those on the the three new units announed by Tascam that use the Ultra-HDDA preamps (namely the US 2x2, 4x4, and 16x08.) And it would be ideal for me if some such big brother audio interface had S/PDIF connectors instead of the AES/EBU connectors. Only 2 inputs is enough for me, but I do want high quality sound and prefer ultra-low latency performance in an audio interface. I've got to say, though, that this news, henceforth, is exciting!
 
I'm really looking forward to getting that UH 7000. That little joker is very impressive with the hardware inside!
2014/10/11 02:31:50
Anderton
The UH-7000 is not a low-latency device on the order of the RME and uses third-party drivers. Its latency performance is average, 13-20 ms depending on your computer, track load, etc. The PreSonus article I linked to previously explains why round-trips in that range are commonplace. I consider 13 ms fine for playing guitar through amp sims, which is what matters most to me about latency. I'd prefer under 10 ms, but can certainly cope with 13 ms.
 
That said, the preamps are phenomenal and the circuit design is exemplary. The crosstalk really benefits by having separate power supplies for each channel. The circuit board layout is outstanding and the construction is excellent. The mic pres are discrete. TASCAM is also marketing the UH-7000 as a high-quality stereo mic pre, not just an interface. IF this is representative of the future direction of their hardware, and they can cut the latency by 33%-50%, they're going to be a real contender for interfaces.
 
To me there's not a whole lot of difference in feel between 5 and 7 ms. Practically speaking, I think there are basically three latencies...under 10 ms (good), between 10 and 20 ms (mostly acceptable), and over 20 ms (not acceptable). If I track guitar with headphones instead of listening through monitors, that avoids another 4 ms of latency due to the distance between my ears and the monitors.
2014/10/11 03:36:07
Tshepo#2
These are exciting developments. I'm looking forward to the results.
2014/10/11 04:18:31
backwoods
That uh7000 does look pretty cool :) as you say Craig if they can cut the latency by about a third that would make it very attractive.

I got a studio capture and can't complain but that new 16x08 would look better in the rack!
2014/10/11 04:25:49
thomasabarnes
Anderton
 
 the preamps are phenomenal and the circuit design is exemplary. The crosstalk really benefits by having separate power supplies for each channel. The circuit board layout is outstanding and the construction is excellent. The mic pres are discrete. TASCAM is also marketing the UH-7000 as a high-quality stereo mic pre, not just an interface. IF this is representative of the future direction of their hardware, and they can cut the latency by 33%-50%, they're going to be a real contender for interfaces.




Hi Craig:
 
TASCAM would certainly be able to compete with the best, if they can get hardware such as the UH 7000 to perform at ultra low latencies.
 
The reason I threw out the low latency numer of 8.2 ms roundtrip is because my UltraLite mk3 performs well at that latency under heavy load projects, without cracks pops and dropouts, such as is the case with the SONAR demo songs. I can be OK with that kind of performance from an audio interface.
 
I primarily use virtual instruments in my music creation. When I'm laying a track with a Vi, I want smooth playback. Using a 20 ms or lower round trip latency setting is OK at the beginning part of a project, but when adding more tracks, Vis, and effects, crackles, pops, and dropouts start to occur unless the ASIO buffer size is increased. And higher ASIO buffer sizes cause the delay of sounds for virtual instruments, and when trying to record them, that is unsatisfactory. However, at a round trip latecy of 8.2 ms or lower, I experience no delay problems. That's why I can be OK with that number I threw out there. 
 
Consequently to something you said above, it certainly makes me start to thinking, as it seems like you're alluding that the in house driver team wont be writing drivers for the UH 7000. That seems wierd to me since the unit was just released earlier this year, but I don't know all that's involved in the TASCAM decision concerning that matter. If TASCAM will only be writing drivers for the gear announced very recently, at least, that's some kind of good intention start.
 
The UH 7000 is an impressive piece of hardware! I hope the drivers can be improved for better low latency performance. It's something else how it always seems to be when something great comes along, there are its weaknesses as well as its strong points.
 
I do, however, think that TASCAM and Cakewalk can do great things together!
 
Cya around.
2014/10/11 09:48:04
hockeyjx
I've never had latency problems with my trusty FW-1884! What is everyone using for testing? DPC Latency Checker? I may run that to see what that 10 year old unit gets.
2014/10/11 10:27:50
brconflict
Since I figured out how to compensate (to the sample) for latency in hardware, I've not seen latency be a real problem for me. The only thing I wish for is a Low-latency [Echo] button in Sonar, where I can use a compressor on the armed channel I'm recording vocals on.
 
I really don't get why that still doesn't exist. I think the Echo button is not placed into the chain at the right place, maybe. If, by enabling the Echo button, the armed track wouldn't care how much plug-in delay it or any other channel creates and simply play back the armed track's audio as fast as possible, we could have a better Echo capability. In other words, the Echo function shouldn't care or be affected by plug-in delay compensation, because the singer won't be concerned with it, either.  She's going to sing to the audio playback she hears. If the plug-in delay is applied to what's written to disk (to sync the recorded audio to the project) vs. what's heard back in the Echo function...maybe?
 
So, why is this a concern to me? I know I can disable all plug-ins, but singers like to sing along to a real mix, and have some compression applied to their incoming vocals as it's echoed back into the cans. Disabling all plugins is unappealing, since we've been able to use compressors while tracking for decades. I have an old Yamaha AW4416 that allows the singer to hear the tracking vocal with compression and absolutely no delay.
 
Anyway, that's where I find the absolute biggest delay problem is that old funky Echo function (and since MOTU wasn't nice enough to allow their CueMix software use a plug-in or two).
 
 
© 2026 APG vNext Commercial Version 5.1

Use My Existing Forum Account

Use My Social Media Account