Yeah, my question is mostly, what would have been the generation times. Personally I would favor having the possibility for slower onboard analysis, than none - but if it would take i.e. 30 min for a 3 minute that can be considered not usable in reallife scenario. But selecting a song further down the playlist and have a 6 - 10 minte background process would be okay from my pov.
There were no âfalse promisesâ - just misunderstandings from ill informed customers.
It was only ever a beta test. They didnât âpromiseâ anything.
They never sold it as having stems.
Some people clearly failed to understand the difference between a beta test and full release. Some retailers also advertised it as having stems, even though it did not.
I do understand what you mean here.
Personally, I would phrase it a little differently though.
I do not think the main issue is whether there was a legally binding âpromiseâ or not.
The bigger issue is that the overall marketing, public demos and early communication around the PRIME 4+ clearly created the expectation of standalone real-time stems functionality.
Terms like:
âworldâs first standalone stemsâ âreal-time stem separationâ âwithout a laptopâ
were used repeatedly in marketing coverage, preview videos and public demonstrations long before the later âpre-rendered stemsâ clarification appeared.
The later beta demonstrations did not suddenly create that expectation â they reinforced an expectation that had already been built beforehand.
So for many users, the issue was less: âa guaranteed feature was not deliveredâ
and more: âthe final implementation did not fully match the expectation that the public communication had created.â
And regardless of how some people may try to reinterpret this afterwards, many users clearly came away with exactly that understanding at the time.
That perception did not come out of nowhere.
I remember a time not so long ago, when I used to explain on this forum that products equipped with an RK3288 chip would never get real-time stems (and even less so in high quality) and that the System One - being equipped with an RK3588 and 4 GB of RAM - would at best only obtain a background track separation processing mode which would not be fast enough to perform processing in an acceptable time to be usable on the fly; Many people on this forum told me I didnât know what I was talking about, that only developers could know what the hardware was capable of and what it wasnât, and that it was all just a matter of optimizationâŚ
And today, well⌠we have proof by example⌠Older generation hardware will never have onboard stems of any kind, and the RS1, supposedly a next-generation device with an ultra-fast CPU (dating from 2020), struggles to separate a track at approximately 1x and has to settle for queued processing in the background.
At the same time, I want to say that you didnât need to be a genius to understand that if software like Serato or VDJ requires hardware specifications worthy of NASA PCs, with at least 16 GB of RAM and super-powerful GPUs to process this type of separation algorithm, then InMusic, with its Chinese tablet CPUs dating from 2014 and 2020 respectively and made by Rockchip, certainly isnât going to work miracles.
And donât tell me again, âYes, but thereâs no Windows, thereâs no need for such high specs in a standalone product.â
And I remind you that the stems separation algorithm currently used by Denon is barely more efficient in terms of rendering quality than stems V1 used by VDJ in 2019⌠yet itâs relatively lightweight, and the RSone is already at the end of its lifespan trying to process it. So, regarding stems V2 with artifact-free stems⌠you can expect to multiply the current rendering time by at least 4.
I hope thatâs clear for everyone now.
Oh, and Iâm eagerly awaiting the âItâs better to pre-render tracks anywayâ and âStorage is cheap these daysâ crowd who will try to find excuses to justify things no matter what.
Nice write-up. From your experience what would generation times be on the older hardware?
More accurately - DJ hardware, as older generation MPCs with the RK3288 CPU do have onboard standalone stem separation.
Itâs slow and it ties up the machine, but itâs there.
Iâm afraid the problem with older generation equipment isnât really framed in those terms.
In theory, the RK3288 could process stems with the Stems V1 algorithm, even if the process is time-consuming. But the CPU isnât the only limiting factor on older hardware.
One of the biggest limiting factors is the onboard memory, which is only 2GB.
A significant portion of the RAM is already occupied by Engine OS, services (Engine Lighting, streaming services, Ableton Link, etc. â each activated service eats up a little more RAM), effects, and especially the caching of tracks when you load them onto the decks.
This is why four-deck devices like the Prime 4/4+ and SC Live 4 are more prone to slowdowns or audio dropouts, because the amount of RAM is still only 2GB spread across four decks. Dual-deck/two-layer devices are less likely to reach RAM saturation limits because you can only load two tracks at a time.
When rendering stems, you generally have two options:
Either the rendered stems are temporarily stored in RAM for immediate access (this is the case with Serato/VDJ, which is why at least 16 GB of RAM is required).
Or the stems are first pre-rendered, stored locally, and then partially or fully loaded into RAM when the track is loaded onto the deck. This is the case with the RSOne, thanks to its 4 GB of RAM, which provides a bit more headroom and is sufficient for a dual-deck device.
Keep in mind that a track rendered as stems is actually just a set of four sub-tracks that are loaded simultaneously, and you can choose whether or not to mute them.
And these four sub-tracks weigh approximately the same as the original track. Furthermore, itâs highly likely that, given the processorâs limitations, the tracks should be rendered as WAV files for storage in memory. This avoids the device having to re-encode each track to MP3 before storing it in RAM. And, of course, WAV files take up significantly more RAM.
Moreover, itâs important to know that the stem algorithms, whether Stems V1 or V2, are configurable during the development stage. Developers must find a balance between rendering time and rendering quality based on the processing power of the machine on which the algorithm will run.
The faster the rendering time setting, the less precise the separation the algorithm will perform, and the more muddy the sound will be, with more artifacts. Conversely, the higher the quality setting, the slower the processing time and the more precise the separation, but also the more RAM is used during the separation process.
Finally, the more stems you want, the more resource-intensive and time-consuming the process becomes.
This is why, during the live stem rendering tests on Prime 4+, the development team likely faced dilemmas regarding RAM management. They attempted to make trade-offs between rendering time, rendering quality, and limiting the number of stems rendered to two (instrumental/acapella) to find a balance and avoid overloading the RAM.
However, it turned out that this balance was probably too difficult to achieve on this generation of hardware to guarantee a quality experience for the end user. Neither the rendering time, nor the quality, nor the number of stems was truly satisfactory in the test feedback.
It was still good that they tried, but I think they were right not to pursue it further because ultimately people would have complained anyway, as the experience wasnât satisfactory. And I think they want to offer an experience that is at least acceptable. Thatâs why the solution chosen for the RSone, with its 4GB of RAM and pre-rendered background processing, seemed to them to be a minimum acceptable level. Even if itâs only a first step before getting hardware that will truly have the processing power necessary for real-time, high-quality separation. But weâll have to wait for the next generation for that.
The case of the older MPCs based on the RK3288 isnât entirely comparable; you couldnât do anything while the process was running on the machine, and you could only separate a small part of a track, not an entire track.
I did say it ties up the MPCâŚand what makes you think itâs not possible to separate an entire track? I know MPC users typically only work with small loops, but people have definitely separated whole tracks.
I can time it on my MPC X SE if you want proof.
Iâm not saying itâs impossible to separate entire tracks on the MPC; itâs certainly doable, but extremely slow. And above all, the very nature of the MPC, which is oriented towards sample processing, means that you generally wonât want to separate entire tracks, just process certain parts of a track.
I mean, if youâre using an MPC to process a 10-second segment, for the intended purpose, even if you canât do anything else on the device during the process, thatâs acceptable.
But in the case of using a DJ product where youâre only processing entire tracks and not samples, having your device tied up during an extraction process that could last more than twice the playback time of your track is probably not an acceptable situation.
Understood 
Yes Iâm aware they have different use cases, and separating for production doesnât need to be done on-the-fly or in the background - I was just commenting on your statement that âOlder generation hardware will never have onboard stems of any kindâ. 
Google translation is sometimes a bit simplistic and doesnât quite express what I meant.
And thatâs the key difference: on an MPC, this type of process is primarily done in a studio as part of a production workflow.
A DJ product, on the other hand, is geared towards live use. So, locking your unit during the extraction process is clearly not a viable solution for entire tracks in this context.
So yes, theoretically, the development team could probably have released the feature with a setting that prioritized rendering time at maximum speed, but that would have been at the expense of the final output quality. Therefore, people would have complained that it wasnât usable in a live setting anyway.
Like every other member here, your express your opinion, and not some universal truth. So get off your high horse, will you?
Yes, I am part of said âcrowdâ who already stated it, and will do it again: If you prepare your tracks ahead anyway (waveforms, beatgrids, Cues, Loops, playlists, etc.) you can do pre-render Stems just as well. Yes, they take up more space, but nobody forces you to create Stems for all of your 50k+ or whatever amount of tracks. Focus on your core playlists and the required extra space is certainly manageable. If you have the money for some expensive DJ gear, paying the extra bucks for a larger SSD drive should be no show-stopper.
The alternative would be to build a much more potent chip into every Engine DJ unit, to gain anything near 10-15x analysis speed (and you state it yourself, that going V2 would require even more chip performance), which would result in the unit price becoming more expensive for everyone, including the people who would never or only just very occassionally make use of this standalone Stems analysis feature, like me. For every other feature (regular operation, track analysis, waveform rendering, engine lighting, streaming, etcâŚ) the RK3588 is perfectly balanced and based on the similar architecture like the legacy 3288 family. Itâs really not that hard to grasp. Also, R&D, prototyping and testing needs time. Chip development and iterative releases are faster than that, which is part of the reason the SC5000, released in 2017, is based on a 2014-era RK3288.
The biggest point you seem to miss: None competitor has standalone Stems playback capabilities at all (not even pre-anlayzed) one. So rather than complaining about any chip/RAM limitations and whatever, you should regard the added on-board Stems analysis as small but nifty emergency bonus, on a device with motorized platters and high quality faders/materials, which is still 20-25% cheaper than a XDJ-AZ.
As for the older generation: No, I donât think that on-board Stems analysis will come to older, RK3288 based devices. Eventually itâs time to move on, and we really canât complain about any lack of long-term software support, see the recent 5.0 release. The only valid point of critisims in that regard would be the questionable marketing / âleaksâ in terms of the P4+. This wasnât their finest hour, sure. But I would never buy any product based on promises aka âcoming laterâ anyway, and instead wait a bit. Leaving aside, the 2-split Stems of the beta sounded like crap anyway, so I would pick a superior sounding 4-split Stems, rendered ahead, anytime.
Nothing about âmaking excusesâ (why should I, I donât work for inMusic), I am just being realistic and pragmatic, and I wish more forum members would be when it comes to expectations on certain feature requests or limitations.
Another thing thatâs worth mentioning about the Akai MPC system is that it offers you the choice of which stems youâd like - so if you only want the vocal, you can have just that part.
Maybe Rane should consider doing that on the System OneâŚ
Iâm not here to complain, I was just giving a little reminder to all the people who jumped on me back then, saying I didnât know what I was talking about.
Of course itâs still better than what the competition is doing⌠for now⌠And of course itâs a first step.
Obviously, Iâm among those who would have preferred that InMusicâs R&D team make a bigger leap forward in terms of the embedded chip, because as you so rightly point out regarding SSDs, if youâre buying expensive DJ equipment, spending a little more money isnât a problem. And personally, Iâd rather spend an extra âŹ150/$150 on a better chip than spend that same âŹ150/$150 on an SSD⌠because with a better chip, I simply wouldnât need an additional SSD to store my stems.
But I suppose everyone has their own priorities.
Interesting insights all. Inmusic has made the decision. Its clear that better hardware would allow better capabilities against a cost; however performance/pricewise the standalones will not be able to compete with laptop capabilities. In my opinion the only way is to offload cpu intensive tasks to another machine (local or cloud service). Ie for generating Stems while performing, a similar technique to EngineDj remote library might be used. Give the laptop the task to quickly generate stems and download them over the network to device. Obviously upfront prep on laptop is better, but then quality of stems should be competing with the best stems in the market (ie vdj).
The âpureâ stand alone onboard stem generation to serve as a backup solution.
Seems to me inMusic is increasingly putting themselves in the corner by focusing on all in one devices (most popular with mobile DJ/home DJ market) while not being able to deliver the same features or reach the same quality of features as the laptop+controller combo (that markets most popular type of gear).
5.0.+ update is underwhelming (another critical bug that was not caught in testing slipped, no FX work, some old bugs still remain)
No news about next gen single deck devices or mixers
Money is being spent on buying NI with dividends of that to pay waaay off in the future.
INmusic? More like OUTmusicâŚ
Yes, positioning all InMusic dj brands in the more expensive stand-alone niche seems like a dangerous move. Therefore I do think that EngineDJ desktop performance mode is not too far away. In the end itâs an ecosystem-competition.