X32 Rack Killer?

[RoadRanger]

[video=youtube;sicZ2nH6ImQ]

http://www.smproaudio.com/index.php/...al-mixers/umix

http://www.smproaudio.com/umixweb/

 

Projected U.S. MAP pricing:

uMiX Mini - $249.00

uMiX 12 - $499.00

uMiX 16 - $699.00

uMiX 24 - $999.00

[twostone]

Interesting looks like they use Wave's eMotion GUI but limited Multi-rack features. Just wonder what happen if the wifi signal craps out ?

[RoadRanger]

Interesting looks like they use Wave's eMotion GUI but limited Multi-rack features. Just wonder what happen if the wifi signal craps out ?

They also have wired ethernet.

[OneEng]

They are using HTML5 for a programming interface.

 

When the uMIX16 is compared to the X32 Rack:

1. Multi-track requires additional card
   
2. Limited efx control
   
3. 3 band vs 4 band channel eq
   
4. 16 inputs vs 22
   
5. No digital snake
   
6. 8 vs 14 outputs
   
7. 3 vs 8 efx processors
   
8. No gates on channels
   
9. No flexible routing
   
10. No MIDI input or output
    
11. No P16 like IEM support
    
12. No physical interface (although the X32 Rack has only a very minimal interface, you can still do things on it)
    
13. No assignable controls
    
14. No DCA's
    
15. No Matrix mix buses
    
16. No free audio multi-track software
    
17. No center channel support
    
18. No offline show/scene editor
    

Arguably, considering the price, I should be comparing the uMIX24 instead of the 16.

 

I think that this product will compete more with the DL1608 and Behringer X18.

 

While all of these comparisons are interesting to list on a post, the real test is if it sounds any good.

 

On my PC, I already found many lockups and bugs in their UI. I am NOT a fan of HTML 5..... and neither is Mark Zuckerburg. After having abysmal performance for Facebook on the mobile applications, he was forced to do a complete re-write away from HTML5 to fix it. Additionally, every version of every browser renders the code differently leading the a crazy amount of instability and inconsistent operation.

 

Still, there are those who are predicting that the performance issues will be resolved and that standards will consolidate and HTML5 will be able to compete with native compiling.

 

I am always interested in new competitive products in live sound though! This one is definitely out there on the fringe of new technology. I wish them good luck.

 

 

[abzurd]

Not the prettiest hardware and GUI, but VERY smart to the browser be the wrapper so you can use anything that can support HTML5. That second link you posted is pretty sweet. It's like a fully working GUI. For the price point it looks crazy good if the DSP is decent. They've taken some design and function cues for Mackie for sure with the "uMix" button at the upper right corner that shows a sliding side menu. On my screen I can see 24 channels at a time and use my mouse and keyboard to get around pretty darn quickly.

[JV90]

Interesting, but still need for an iPad; it sure looks great, but I'd have to stick then with Apple, and that's the break that put on me.... Android is the way to work

[JV90]

Interesting, but still need for an iPad; it sure looks great, but I'd have to stick then with Apple, and that's the break that put on me.... Android is the way to work

[WynnD]

The point of using HTML5 was to allow any modern browser to be able to remotely control it. PC, Mac, Ipad, Android...... That aspect I like. Totally cross platform. There are time when I wish I could use my MacBook to remote my DL1608. Doesn't work.

[abzurd]

Interesting' date=' but still need for an iPad; it sure looks great, but I'd have to stick then with Apple, and that's the break that put on me.... Android is the way to work[/quote']

What are you talking about? They must say 10 times in the video that you can use any HTML5 device you want. So it's not tied to Apple in the least. You can use Linux, windows, OS, Android, anything that has a browser that uses HTML5.

 

The idea of using it like a stage box is a great idea as well. You'd have to be a little careful, but wow, what a great way to keep the stage clean.

[abzurd]

Just read there is an optional multi-track recording card for the 16 and 24 channel versions. You can also cascade some of them and get up to 48 channels. On paper these look extremely promising. Making them "app-less" is just so freakin' smart. I don't know anything about software development, but it seems easier and cheaper to use HTML5 than home brewing an app for every platform you want to use. Do any of the big boy mixers use browser based remote apps?

[RoadRanger]

Making them "app-less" is just so freakin' smart. I don't know anything about software development' date=' but it seems easier and cheaper to use HTML5 than home brewing an app for every platform you want to use. Do any of the big boy mixers use browser based remote apps?[/quote']I know the Phonic iS16/Acapela planned to use HTML5 but they couldn't get acceptable performance so went with native apps .

 

[sibyrnes]

What are you talking about? They must say 10 times in the video that you can use any HTML5 device you want. So it's not tied to Apple in the least. You can use Linux, windows, OS, Android, anything that has a browser that uses HTML5.

 

Yeah, he mentions the use of an Android within the first minute of the video. Mac hating must somehow affect the hearing!

 

 

[OneEng]

Just read there is an optional multi-track recording card for the 16 and 24 channel versions. You can also cascade some of them and get up to 48 channels. On paper these look extremely promising. Making them "app-less" is just so freakin' smart. I don't know anything about software development' date=' but it seems easier and cheaper to use HTML5 than home brewing an app for every platform you want to use. Do any of the big boy mixers use browser based remote apps?[/quote']

 

Hi Abzurd,

 

I have researched this pretty deeply since HTLM5 is one of my departments potential development environments for our next generation tools. I have had a couple of developers working on this for a couple of months. Here is what we have found:

1. HTML 5 performance is ~5000 times slower than native applications. If you aren't doing anything that requires much HTLM5 logic code (just graphical components updating), this may not be an issue. For us, it was a job stopper.
   
2. HTLM 5 doesn't support threading very well at all.
   
3. HTLM 5 does not currently have access to many of the hardware features of various devices
   
4. A hybrid approach of HTML 5 and native can help with the above issue and some custom wrappers are out there, but this somewhat defeats the purpose of HTML 5.
   
5. HTML 5 implementation varies greatly from browser to browser .... and indeed, even from version of a browser to a newer version of the same browser.
   
6. Not all implementations of HTML 5 support hardware accelerated graphic rendering.
   

There is an on-going debate occurring right now in the software development community over this issue. There are currently 3 major ways to get a single (more or less) set of source code to be used on many different platforms and operating systems.

 

The first is HTML5. This is a browser interpreter so the "code" is presented to the browser to interpret. With any interpreter, there is always a performance hit. Unlike JAVA (which is also interpreted), there are many different people developing the interpreters for the different browsers on the different platforms and operating systems. This leads to huge differences in how the HTLM 5 code behaves depending on your device, operating system, and browser. The advantage is that you truly (unless you use a hybrid approach) have a single source that works across all platforms. HTML 5 applications also rely on Java Script (not to be confused with real JAVA code) which is also interpreted by the browser.

 

The next is just to use different native source codes and different native compilers to make apps on different operating systems. This is very hard to maintain, and takes lots of time to get your development team familiar with the different API's and operating system specific behaviors. It is also a maintenance nightmare. The advantage to this approach is that the performance is outstanding, the executable sizes are tiny since most of the operating system components you use are stored on the device and delivered with the operating system, and all of the features of the hardware are exposed for you to get at.

 

Finally, there are cross-compilers. This class of development creates its own wrapper around the lowest shared level of all operating systems (OpenGL drawing API) and actually uses the native compilers to compile the code targeted for each operating system and device. The advantage is that you can get the performance of a native app, yet have a single source to maintain. The disadvantage is that since you aren't using the GUI component libraries of the operating system, you have to ship them with your app which makes the app size much bigger than a native application.

 

None of these approaches are fully mature as far as our research can tell. I am currently leaning toward the cross-compile approach. I believe this architecture has the best chance of success since the only real obstacle is getting ONLY the components you use to be shipped with your executable to keep the size down. These programs will never be as small as native, but I believe they will get close enough that the other advantages will outweigh the size concerns.

[abzurd]

Thanks for the info. I wonder how different it will react when "connected" because using their demo app is instant.

 

BTW, anyone else not getting email alerts on the new forum? I was for a few days, but haven't for several days now. My settings appear to be right.

[OneEng]

Thanks for the info. I wonder how different it will react when "connected" because using their demo app is instant.

 

BTW, anyone else not getting email alerts on the new forum? I was for a few days, but haven't for several days now. My settings appear to be right.

I am really interested from a professional software standpoint to see how well this works myself. As you point out, the demo works instantly.

[wesg]

Doing more than basic GUI work in the browser is a loser. Mixers don't need more than GUIs on the tablet, ergo, HTML5 is a win. In fact, I was advocating this approach in this forum not long ago... In my environment, we can render graphics faster on the server and push them at the client than we can render to CANVAS. Doing computation on the browser is frequently a loser, although in some cases it performs at half native speed which may be enough. There is lots to understand, though, and it is easy to accidentally make your code slow. DOMworker threads are completely inappropriate for 99.5% of development tasks IME. It should also be noted that more than 80% of developers (by my figuring) do not properly understand browser-land concurrency, and hence think that solutions which work in native application land translate to browser-land. They usually don't. I'm personally not a fan of tools like GWT which cross compile to ES5/HTML5/CSS3, but that is largely because I need to be agile. They do scale well across team size, allowing you to put more folks at once on a given project. You can also have team members who are more specialized in an environment like that, rather than relying on multi-talents individuals. The big problem with them is that you are rowing against the current for your entire project. It is better to embrace the environment and work with it, than it is to try and bend it into something it isn't.

[Dogoth]

They are using HTML5 for a programming interface.

 

When the uMIX16 is compared to the X32 Rack:

1. Multi-track requires additional card
   
2. Limited efx control
   
3. 3 band vs 4 band channel eq
   
4. 16 inputs vs 22
   
5. No digital snake
   
6. 8 vs 14 outputs
   
7. 3 vs 8 efx processors
   
8. No gates on channels
   
9. No flexible routing
   
10. No MIDI input or output
    
11. No P16 like IEM support
    
12. No physical interface (although the X32 Rack has only a very minimal interface, you can still do things on it)
    
13. No assignable controls
    
14. No DCA's
    
15. No Matrix mix buses
    
16. No free audio multi-track software
    
17. No center channel support
    
18. No offline show/scene editor
    

Arguably, considering the price, I should be comparing the uMIX24 instead of the 16.

 

Where did you find all of this information? I went to the site (both links) and all I could see was info about the software and LIMITED info about the hardware. Did I miss a link?

 

Also will it support multiple connections (mains + one or more monitor operators)? Hmmm html5? Not thoroughly tested and bug free but it probably will be soon enough.

 

The price is AWSOME and if it is durable (I always sort of rated SMaudio with Samson or Phonic (although I didn't know they were an Australian company)) and sounds good it might be a great deal for those on a budget. I guess time and the market will tell.

 

[OneEng]

 

Where did you find all of this information? I went to the site (both links) and all I could see was info about the software and LIMITED info about the hardware. Did I miss a link?

 

Also will it support multiple connections (mains + one or more monitor operators)? Hmmm html5? Not thoroughly tested and bug free but it probably will be soon enough.

 

The price is AWSOME and if it is durable (I always sort of rated SMaudio with Samson or Phonic (although I didn't know they were an Australian company)) and sounds good it might be a great deal for those on a budget. I guess time and the market will tell.

 

Here: http://www.smproaudio.com/press/SMPro_Brochure_uMiX.pdf

 

Additionally, I have been hearing lots of praise for the GUI; however, I have found quite a few issues with it myself.

 

Here is a simple one:

1. Open the app
   
2. click on "FX" at the top
   
3. Raise the slider for Reverb
   

You should see serious artifacts that don't go away no matter what you do (at least that is what happens on my version of Chrome.

 

I have also managed to get several lockups in the small amount of time I have fiddled with it. Ether I am a terrific Q/A engineer, or my browser has issues

 

I did just notice that they have implemented "Gains on Faders" which is something I have been asking for on the X32 Rack! Nice.

[Unalaska]

Neat on paper, I'd trust the product more if had a yamaha name on it but since it's SM audio who knows. Not related but I have an SM audio 8 channel preamp, it had 2 non working channels when I bought it so I opened it up. The solder job was terrible, really sloppy all around. I managed to fix 1 channel but still, ug.

[OneEng]

Neat on paper' date=' I'd trust the product more if had a yamaha name on it but since it's SM audio who knows. Not related but I have an SM audio 8 channel preamp, it had 2 non working channels when I bought it so I opened it up. The solder job was terrible, really sloppy all around. I managed to fix 1 channel but still, ug.[/quote']

That is kinda what I was expecting when Behringer started shipping the X32. Perhaps this will be another success story ..... or not

[JV90]

I've never heard from them, and if I use the chrome broswer on my Android cell and tablet I find some delay to move things, but if I use Dolphin browser eventing comes to work at the moment, weird

[voicemaster]

I have tried the beta version using google chrome on my galaxy note pro 12.2. So far, it works pretty good. I found some lag when going through the channel strips, but it is still acceptable. I found no lag with all the faders, it is smooth and precise just like I found in Mackie DL software. I love the idea of universal platforming and trying it with my 12.2 inch android tablet.

[Tvyankee]

Hello,

 

Just thought some of you would like to know that the x32 and s16 are getting some love on a TV show. The man behind the x32 is the man who mixes the Grammy's besides a lot of other big shows. I think he likes it.

 

Thankls

[agedhorse]

Hello,

 

Just thought some of you would like to know that the x32 and s16 are getting some love on a TV show. The man behind the x32 is the man who mixes the Grammy's besides a lot of other big shows. I think he likes it.

 

Thankls

 

Beware of all these "claims", as much of the love is "forced"... not what it appears. I guarantee you didn't see these consoles on the Granmmys, if that's really him, I wonder if he approved of this use of his picture as an "endorsement"? My hunch is no.

[Tvyankee]

Ah Aged. You are right they where not at the Grammy s but he was. He mixes the front of the house for a long time he is a friend of mine. Also this is not an endorsement from him just that he said he liked it for job. He said it worked very well. I myself hooked it up and was very straight forward. It saw the s 16 very quickly . The only thing that was wonky was the that the iPad app and console took some time to see each other. We are using the motu to embed to record our 8ch to our San records. You are right about a lot of crappy tv though and we were doing some of it tonight but it still doesn't change the fact that the console worked well. He uses the Digico to mix front of the house for the Grammy s not the x32. Anyway I just thought people would like to see that the systems works well that guys like him are willing to use it on a TV show.