With the new ARM processors powering MacOS and Now Windows’s. Do we think there is any possibility of new ARM based Prime players, that are powerful enough to handle stems, large libraries (greater than 100k), and maybe even the dream possibility of direct video out.
Welcome back @djstevieray. Were you aware that ARM SoCs are used in these devices?
For non-technical folks, this is a (relatively) good explainer:
For fello tech nerds:
Reeel deep dive:
1 Like
You have to consider the cost of the processors being used by tech giants like Apple and Microsoft too.
A company like InMusic are unlikely to be purchasing sufficient quantities or have the financial clout to develop their own chip in the way those others have been able to.
They say that if you were to try and purchase the equivalent GPU from an Xbox series X it would cost you £1300, yet the console costs £450. That’s what you’re up against.
2 Likes
A snapdragon X plus costs approx $150 and is super powerful. I would be willing to pay double that for fast search and stems on Engine gear.
1 Like
I’m not sure it’s as simple as ‘this will work, let’s connect it to the device’ or that you simply purchase it and it’s plug and play.
Seems like the equivalent of having a car and saying, I’ll just buy this engine and fit it, with no other context or understand around how it might fit.
I’m not sure processors play a massive part in search speed either. I work with a system with huge databases and the more data you have, the slower the searching is. Yes there can be some indexing done to make queries more efficient, but you’re still sending a search into 100000 DB records and it’s still going to take time to look. The new playlist search should help with this, providing your music is arranged into playlists.
Depends on the development toolkit used. Because Engine is Linux based, and crosscompilinh is pretty standard on this platform, everything is probably possible.
But indeed, there are more factors than pure CPU power. I would even say CPU power is probably not the bottleneck for the tasks performed (apart from maybe stems). But there is the R&D cost of new hardware, and Beta testing becomes more complex when maintaining compatible with 2 platforms instead of one…
2 Likes
When you see things like waveform stutters and long random UI pauses / non-responsiveness, one can’t help but think that a low-powered SoC released 10 years ago is the bottleneck. I don’t know this for a fact, but my sense is that the devs have to play loads of games managing CPU time for tasks in order for things to be stable.
You’re 100% correct about R&D Costs for platforms, etc… This is why the SoC used in the current generation of machines are pretty much the same. Add to that bulk purchase pricing, etc… =)
1 Like
The other thing to consider, £150 might not seem like a lot of money for an SOC, but when you consider the SC-Live2 (that everybody will surely expect to come installed with such power for Stems etc) is £800, that now equates to just shy of 1/5 of the RRP on a single component. If we then remove all the VAT, profit margins etc then apply that cost, you’re looking at potentially 1/2 of the total hardware cost being a single chip.
Based on that, lets say they had to make the SC-Live2 £1200 to cover it (ignoring the fact it may need active cooling, a better heat sync, re-arranged boards etc), how many people would be happy with that price bump? and the subsequent price bumps of other gear in the line.
I don’t know how much the current chip costs, but i guess it is nowhere near that.
I think searching by its very nature will be inefficient. Im sure you don’t need any lectures on code and running SQL queries, but if we want to speed a search up on a query we add more parameters to help don’t we, not just SELECT * FROM then all the data.
In Engine when you type say Teddy into the search box its going to be scouring 100000 records of Artist, Track name, file name, comments, album and any other metadata that might contain text, suddenly you might be looking at 600000 different DB records. Its a lot isn’t it.
10 years ago, computers were plenty able to run DJ software. And you probably know as well as me that when running a complex time sensitive task (outputting audio for example), you always have to play games to optimize things. Even on powerful platforms things can go wrong due to for example a memory leak…
Anyway, this is all pure speculation. I’m sure this came up when the dev team discussed stems for example stems, but they have to look at the downsides too. What matters for us is that the platform is running smoothly. How they do it? Should not care…
And regarding running things smooth, yes, there are hiccups. But have you looked at some feature requests? I keep thinking we are bringing this upon ourselves: we want a device that can do our laundry, and then complain that track browsing isn’t smooth. Maybe then we should focus on track browsing, and buy a separate device for the laundry….
1 Like
OK. I am not saying it’s a simple CPU swap. I am asking if we can expect new more powerful hardware sooner rather than later. I can buy an android tablet for under $100 that can run DJay with video and stems.
To address the
SC Live situation with price. How about the SC Live series and Mixstream series can run cheaper hardware that doesn’t have stem capability, no video.
What I am asking for is a premium device that can bury the Opus. If Denon can bring stems and video to standalone first, it would be the most Premium product on the market and still cost less than an Opus.
I think Denon has done great, and everything they have given on the software side, has been wonderful. The problem is. I believe Engine is prepared to go soooo much further, but the hardware is now the limiting factor.
That’s more or less what I meant by doing the laundry 
(but no offence, I understand the use case)
Hardware may be, staffing on the dev team may be as well, management decisions may very well be. OK, implementing features that makes everybody happy is a swamp. But here we are: you ask for more CPU intensive functions, while I just want my remote collection to load instantly, and not after 40 seconds… You understand that it is impossible to cater both of us?
1 Like
The Prime as well as the MPC lines are already ARM Based, but I’d be willing to pay for a companion computer based on OrangePi to handle stems, library management and streaming.
I’d say that historically, video on DJ kit has been hit and miss. Over the years, various companies have tried it, but the products are usually short lived.
Just the other day I was reading about Pioneer (they’re celebrating 30 years of CDJs with a limited edition book) and their DVJ players & video mixer. Now they’re totally out of date.
New hardware takes years to develop. While it’s being developed, a new standard could come along, so by the time it becomes available, the market has changed.
When the Denon HS5500 players came out, they were cutting edge because you could fit hard drives inside. The problem was that Denon chose IDE instead of SATA. SATA drives took over and the HS5500s suffered. They were restricted to 250Gb IDE.
1 Like
I’ve been using Djay on my iPhone 11 Pro and I would suggest saying it ‘runs’ stems is a slightly loose use of the term. It’s certainly noticeable performance wise if you start pushing it.
Which android tablets are you getting for under £90 that can do this with no issues?
GOOD POST… you can see that the CPU of the prime 4 and 4+ would be falling short in performance not too far away, I think the valid alternative would be an evaluation of the CPU, just as they say we look for reliability and stability in the system already saea with any type of tasks. Also understand that there are factors, such as the decisions of the programmers and developers of the system and as well as the executives.
I think it’s important to remember one essential thing, in the case of stem separation, gpu’s are better/faster at running algorithm calculations such as Zplane Pro than CPU’s.
It’s a bit like cryptocurrency mining: GPUs are faster and more efficient than CPUs for this type of application.
In the case of ARM-type SoCs, which integrate a CPU/GPU combination, you should therefore opt for an SoC with a powerful GPU, as this will be responsible for the Stems part.
If you choose a recent SoC with a low-performance GPU and no dedicated AI core, you’ll be no further ahead.
And the more powerful the onboard GPU, the more expensive the SOC.
To sum up, for the use we’re interested in, stems, it’s better to have a CPU with average performance and a GPU with high performance.
We can speculate all we want about CPU performance. But in the end the question is, what are you willing to pay for? Thats the only usefull input we can give to InMusic.
If I speak for myself, I am willing to upgrade my SC6000’s to a SC6000 mkII, IF and ONLY IF the track searching, remote collection loading, and other hiccups/shortcomings in the bread-and-butter area are solved this way. I would NOT pay extra, nor upgrade, for video, stems, or any other exotic functions, which I probably won’t use anyway. I would even consider abandoning InMusic if they would start pushing a mkII device for the sake of “exotic functions”, without having attention to the “bread-and-butter” things. I am a strong proponent of having strong basic functionality before you start to extend your feature list.
(Keep in mind a lot of these simple functions are more a matter of willing to implement them then raw CPU power, so no, just upgrading CPU won’t solve this, company mindset will…)
1 Like
The thing about stems is that they seem useless until you start using them, and especially mastering them. When you start to understand how it can be used and how much it can improve the quality of your mixes and transitions it makes a real difference between someone who practices mixing in its traditional EQ-based form. and someone who practices it using both stems and equalization.
Many people imagine that stems are only used to make bootlegs or mashups live, to put the acapella of a track A on the instrumental of a track B. But in reality it also allows for much cleaner and fluid transitions.
For example, I use extensively in my transitions the echo out effect on the vocals only of track A just before the vocals of track B enter. Or I can only perform a bass stems swap between two tracks (I cut the bassline of track A when the bassline of track B enters) in order to avoid frequency conflicts in the bass.
Or in the same way do an instrumental swap while the vocal of track A is still in progress and the vocal of track B has not yet entered. While keeping the drums activated on both tracks to mix them normally.
This brings so many creative possibilities, for example activating slip mode on the vocal of a track only and scratching the vocal while the instrumental continues to play, deactivating the slip and later resuming normal playback of the track as if you hadn’t done this scratch phase (without having to do an instant double)
I think this has a bit to do with Agile software development methodology. As Sprints (short usually 1 week periods of development time) dictate the time frame, the developers need to rush some times to get the things done before the sprint ends. Then comes evaluation, if the development is good enough for release, it gets a go, if not, then another sprint happens. If there is a set time frame for the whole (let’s say a month), then software needs to be Good enough when it’s time to release. Then you get some smoothing out and bug fixing period, and then another goals are set for new sprints to happen. Google Agile to go more in depth. I don’t say, this is how it goes in Denon, but it is highly possible, as many software development companies use it. For some products it works perfect, for some not really. It all comes to the targets, money, people’s mind set.