Intel is shutting down NUC

[subnoize]

So for those who are interested it "looks like" from poking around in my Push 3 that they are follow something close to the Gen 11 NUC from Intel so the pinout connector is industry standard spacing "edge connector" and the pins are listed in section 2.3.1 of this document;

https://www.intel.com/content/dam/suppo ... D_SPEC.pdf

It really doesn't matter that this module is "discontinued" as its just the PCB and chipset that is being retired. You never notice when other manufacturers change out their motherboard and this will be no different.

The edge connector is common and orderable from Digikey or Mouser which means you can pre-pop it on any of the PCB services.

So we are good, case closed. Time to get back to making music

UPDATE:

For the poor Mac folks, yeah I feel your pain. Every time Apple changes their motherboards they essentiall force a repuchase of everything in your studio. Been there, done that at least 4 times in the past 10 years. I will never do it again as when the last Mac Pro M2 are gone from my studio I will never purchase another Apple product as long as I live, period.

But, let me assure youe right here and right now, this IS NOT the same thing. Only Apple is that stupid....

Anyways, this is a nothingburger and time to wrap it up and get back to making music.

[elbows]

Thats a somewhat strange and technically imprecise way of looking at things, if we are talking specifically about future upgradeability of existing Push 3's. But I suspect that sometimes some of us are talking at cross-purposes with one another. Even if we disregard posts from people that didnt know the difference between the broader NUC product segment and the Compute Elements part of the business which is actually relevant to the Push 3, we can still end up focussing on different angles and technical details that result in our opinions being slightly or far apart.

What actually matters is which Compute Elements are compatible with the other parts of the Push 3 that do the job of being the 'Carrier Board' to use Intel terminology. The technical details of this are the difference maker in terms of what other Compute Element boards beyond the one they've used to start with can be dropped into the existing Push 3 design without any show-stopping compatibility issues.

I say that because some people care about the future upgradeability of their existing Push 3 since this was a feature that formed part of the marketing. This aspect is incompatible with your sentiment that "You never notice when other manufacturers change out their motherboard and this will be no different.". Because we dont get to swap the carrier board when we upgrade, we only get to swap out the Compute Element module that connects to that board via the connector you mention.

So thats one potential issue, which frankly involves some unknowns that would still have existed even if Intel had not transferred this business to ASUS.

The other potential issues involve the feasibility of any future R&D costs for Ableton (and their carrier board design partners assuming they arent doing everything in-house) should they need to change the internal design of the Push 3 in future.

Again, some of these possible future issues would still have existed if Intel had stayed in this business, and it comes down to the planned lifecycles of all this stuff, various technical details that are not available to outsiders and people who have not signed up to receive access to all the confidential information of Intels official Reference Designs.

Personally when I purchased the Push 3 standalone I made no assumptions about what upgrades would actually be available in future. And nobody other than Ableton can actually offer me concrete information and reassurances, because they know the detail of the design of their product. So in some ways the switch of this business from Intel to ASUS doesnt change much for me at this particular stage. If there are additional implications then I dont really expect them to become clear at this stage. And there are plenty of other factors that can affect product viability and future plans that have nothing to do with this technical stuff, eg how many Push 3 standalone versions get sold in the months and years ahead, how the reputation and desirability of the product evolves, how profit margins evolve, etc etc. All things where outsider speculation wont properly fill the knowledge gap, and where I am content to live with a degree of inevitable uncertainty.

[Audivit]

Thank you @elbows
I find your point of view very smart and fair.
It does resonate with my experience and thoughts on this topic.

[elbows]

Thank you @elbows
I find your point of view very smart and fair.
It does resonate with my experience and thoughts on this topic.

Thanks.

It would be easier to make assumptions and offer a much simplified opinion if the equivalent to 'motherboard and CPU compatibility' details for multiple generations of Compute Elements and Carrier Boards was more readily available, understood and discussed publicly online.

In fact some parts of this puzzle are available, but I tend to be reluctant to assume that I've interpreted them all properly, and some of the most heavily focussed on by normal consumers and suppliers online arent relevant (eg Extreme elements that have a different form-factor to the smaller modules used in the Push).

The most positive example I've found so far that is hopefully relevant to the Push 3 is that a product brief from Intel for the NUC 13 Compute Element contains the line "Backward-compatible with Intel® NUC Board and Pro/Rugged Chassis". Which implies that if the parts of the Push 3 that act as the Carrier Board are technically exactly equivalent to Intels own generic NUC Board, the 13 series Compute Element modules could indeed be directly dropped into existing Push 3 devices. I cannot quite make this assumption with 100% certainty, and any small caveats that could exist might make a biug difference to the Push 3 for all I know, but I might hope that this backwards compatibility is the case and so will also carry over to the initial offerings from ASUS.

Source of the backward-compatible quote is https://www.intel.com/content/www/us/en ... brief.html

[subnoize]

Thats a somewhat strange and technically imprecise way of looking at things, if we are talking specifically about future upgradeability of existing Push 3's.
...
What actually matters is which Compute Elements are compatible with the other parts of the Push 3 that do the job of being the 'Carrier Board' to use Intel terminology.
...
This aspect is incompatible with your sentiment that "You never notice when other manufacturers change out their motherboard and this will be no different.". Because we dont get to swap the carrier board when we upgrade, we only get to swap out the Compute Element module that connects to that board via the connector you mention.
...
The other potential issues involve the feasibility of any future R&D costs for Ableton (and their carrier board design partners assuming they arent doing everything in-house) should they need to change the internal design of the Push 3 in future.
...
And nobody other than Ableton can actually offer me concrete information and reassurances, because they know the detail of the design of their product.

I, a hardware developer and implementer do not care what the connector looks like. I care what protocols I have to support.

The protocols used by the SBC in the Push 3 is USB 3, USB 2 and PCI. All 3 of those are standards are available for developers like myself to implement and use (with small licensing fees for the USB stuff).

In fact there is nothing stopping Ableton from using ARM and moving in that direction as far as I can see. Ableton would have to had ported large portions of their code to ARM to support the new Macs. Why not offer a new module using ARM instead? Why stick with Intel? If the rumor is correct the Intel platform was choosen because the Mac version of Ableton was easier to port to the Linux kernal anyways (I am skeptical of that rumor though).

You see the NUC, I see a set of protocols. I see ARM coming, probably not the next module but maybe the 3rd or 4th. I am not sure why you are all hung up on some silly Intel PCB. Call me back in 7 years when we are all buying our new Push 4s and lets discuss what actually happened.

And nobody other than Ableton can actually offer me concrete information and reassurances, because they know the detail of the design of their product.

Have you not noticed that Ableton has no intention of changing their plans?

[dcjams]

Right, as we all seem determined to flog this one to death , I'm going to 'chip' in again.

Here's a pic of the upgrade kit from Ableton. Presumably the thing top left is the processor upgrade. There appears to some kind of assembly or mounting and then a second device labeled Intel within it.

What exactly are we looking at? Who makes what bit? Which bit is the NUC? What's being retired by Intel? What's proprietary? What are ASUS likely to manufacture that's identical? Needing no redesign in other words. Etc.

My guess is, the square is proprietary and specific to Push. The rectangle labeled Intel is the NUC. Inside the NUC is an Intel chip. Intel will continue to manufacture that chip, ASUS will take up the reins and manufacture the rest of the 'rectangle' and it will be identical (in how it connects to the 'square' at least). Identical because the 'rectangle' is not unique to Push. It could well be used by other devices out there in the world in all sorts of sectors.

I assume Ableton don't own any manufacturing or fabrication facilities themselves and anything proprietary involves a partner other than Intel.

[elbows]

I, a hardware developer and implementer do not care what the connector looks like. I care what protocols I have to support.

The protocols used by the SBC in the Push 3 is USB 3, USB 2 and PCI. All 3 of those are standards are available for developers like myself to implement and use (with small licensing fees for the USB stuff).

At Abletons own internal level of development, what I would care about when considering ARM was whether any 3rd party hardware development partner was actually going to deliver an ARM module that offered a compatible drop-in replacement.

Certainly we can see what types of signal each pin on the module utilises, much of which aligns with the protocols and bus types you mention, eg pages 14-18 of https://www.intel.com/content/dam/suppo ... D_SPEC.pdf

In fact there is nothing stopping Ableton from using ARM and moving in that direction as far as I can see. Ableton would have to had ported large portions of their code to ARM to support the new Macs. Why not offer a new module using ARM instead? Why stick with Intel? If the rumor is correct the Intel platform was choosen because the Mac version of Ableton was easier to port to the Linux kernal anyways (I am skeptical of that rumor though).

Porting to ARM on Mac is a different proposition to porting to ARM for other operating systems. Because of the amount of stuff Apple made relatively trivial for developers via Apple tools and compilers. How much additional work Ableton would have had to do for the Apple port would require me to have more knowledge of their code and what 3rd party libraries they utilised, and how much they already relied on Apples own compiler tools etc in the first place. In practice the situation might end up requiring a similar degree of work when dealing with other operating systems (Linux) and ARM implementations, or it might involve more work, I cannot say. That they have a version of Ableton (minus GUI) that runs on Linux is certainly a good start, but I'd have to learn more about ARM versions of Linux and the supporting compiler chain, and the ARM compatibility state of all the libraries used to get a better picture. I certainly dont rule out the possibility if all the stars align on both the hardware and software side of things, especially given more time for 3rd party libraries etc to mature their ARM compatibility.

Have you not noticed that Ableton has no intention of changing their plans?

I would not expect any changes to medium-long term intentions to be visible at this stage, and I have no intention of presuming to know their intentions on that front, because I am an outsider not an insider. And I didnt claim the sky was falling in in the first place, only that there could in theory be some implications but its not posible to draw conclusions from the outside.

[elbows]

Right, as we all seem determined to flog this one to death , I'm going to 'chip' in again.

Here's a pic of the upgrade kit from Ableton. Presumably the thing top left is the processor upgrade. There appears to some kind of assembly or mounting and then a second device labeled Intel within it.

What exactly are we looking at? Who makes what bit? Which bit is the NUC? What's being retired by Intel? What's proprietary? What are ASUS likely to manufacture that's identical? Needing no redesign in other words. Etc.

My guess is, the square is proprietary and specific to Push. The rectangle labeled Intel is the NUC. Inside the NUC is an Intel chip. Intel will continue to manufacture that chip, ASUS will take up the reins and manufacture the rest of the 'rectangle' and it will be identical (in how it connects to the 'square' at least). Identical because the 'rectangle' is not unique to Push. It could well be used by other devices out there in the world in all sorts of sectors.

I think the imagine of 'the square' is misleading. At least one video of someone opening up a standalone Push 3 reveals that actually that part is a standard silver-coloured oblong Intel Compute Element. I suspect that that image of the square includes removable packaging that this part ships in, and probably some of the other connection wires for wifi etc, giving a misleading impression of the main modules form factor in that photo. We already know the part number of the exact Intel Compute Element used, although I do not have it to hand right now.

Indeed Ableton these days provide a page that talks about 'Push 3 upgradeability with third-party parts'. What it says is what we might expect, that technically other off the shelf parts might work, but that there are warranty implications and additional isues to contend with to get these parts in the right state to function inside the Push 3:

https://help.ableton.com/hc/en-us/artic ... arty-Parts

While it is technically possible to upgrade Push 3 components with third-party parts, using parts that aren’t from Ableton could be hazardous and will void your warranty. We cannot guarantee that any third-party parts will be fully compatible with Push.

Processor section mentions:

Information and tips to consider:

The chip's BIOS settings must be configured properly; this is not a "plug-and-play" upgrade scenario.

[subnoize]

Porting to ARM on Mac is a different proposition to porting to ARM for other operating systems. Because of the amount of stuff Apple made relatively trivial for developers via Apple tools and compilers...

That is a fundamental misunderstanding of programming in general.

In modern software development we have learned to abstract operating systems and hardware away from the core of our applications.

I will assume a lot in the next few statements because I trust Ableton's developers to be current with industry best practices.

I would be willing to bet that very, very little of Ableton's code is in assembler. Maybe 3%? Assembler would be the only code specifically tied to chip architecture (but this would NOT be tied to the chipsets on the NUC PCB as that would be encompassed in the OS level, this would be CPU specific).

I would be shocked if (not counting the UI) if Ableton has anything north of 7% of their code in OS level operations. This would be those calls to the various bus using whatever protocols. Thus this would encompass the PCIe and USB 2/3 communications.

Obviously 100% of the UI code would be OS specific. That is why we separate this layer from the actual logic of our applications. UI code is also the single largest part of any application as feature rich as Ableton Live is. I would guess that roughly 60% of Ableton Live is actually specific to UI.

I am willing to bet my last $1.50 that the Ableton Core is 100% the same between MacOS and Windows. That is why we call it the "Core."

So, in the case of our Push 3 standalone, there is no UI. All of that code is gone. The Standalone SBC is using the USB 3 bus to access the pads, the knobs and writing to the screen. Which is why when you plug an external computer into the USB 3 you have to switch to Control Mode. That releases the USB 3 bus to the external computer (and should have been your first clue as to how this thing works, you can't access the SBC from the external computer through that USB 3 port). That is because the hardware for the Push3 (not the Standalone SBC) can only be connected to one host at a time.

So what you clearly have not considered is the Standalone SBC doesn't even have a UI and is depending on the CPU/MCU in the Push 3 itself to provide those functions (screens, menus, knob and pad readers). The Standalone SBC is ONLY the Core and the HAL (hardware abstraction layers) created by Ableton.

Ableton doesn't have much to port.

Funny note, the sound card in your Push 3 is also removable is USB 3. These dudes are serious about upgradability.

Lastly, the SSD and the Wifi cards are both on the PCIe bus which is as expected. There is no direct connection to the SBC.

[Audivit]

So the Audio Interface is on the USB3 bus...
Interesting as I found the Push 3 has "not so impressive" latency performance.

Since the NUC Element has 3 lanes for PCIe (1x PCIe x4 Gen 4, 1x PCIe x4 Gen 3 and 1x PCIe x1 Gen 3)
I wonder why they didn't use the last one to squeeze some latency in Standalone Mode, and maybe switch to USB3 in Controller Mode?

Maybe wasn't worth the extra hassle for shaving a few milliseconds of latency?

[elbows]

That is a fundamental misunderstanding of programming in general.

In modern software development we have learned to abstract operating systems and hardware away from the core of our applications.

I will assume a lot in the next few statements because I trust Ableton's developers to be current with industry best practices.

I would be willing to bet that very, very little of Ableton's code is in assembler. Maybe 3%? Assembler would be the only code specifically tied to chip architecture (but this would NOT be tied to the chipsets on the NUC PCB as that would be encompassed in the OS level, this would be CPU specific).

I would be shocked if (not counting the UI) if Ableton has anything north of 7% of their code in OS level operations. This would be those calls to the various bus using whatever protocols. Thus this would encompass the PCIe and USB 2/3 communications.

Obviously 100% of the UI code would be OS specific. That is why we separate this layer from the actual logic of our applications. UI code is also the single largest part of any application as feature rich as Ableton Live is. I would guess that roughly 60% of Ableton Live is actually specific to UI.

I dont think thats actually incompatible with my point, which was that when dealing with porting mac software, Apple made things relatively trivial because if you use their APIs etc, xcode and compilers can do almost all of the work for you. The abstraction you mention enables this for the swathes of OS-specific code in the mac version.

How Ableton have dealt with this side of the code for the Linux version is unknown to me, since they obviously cannot make use of Apple APIs and Apples own ARM stuff for that. And in any case, at no stage have I assumed anything excessive such as the need for a complete rewrite of huge parts of the system.

Certainly the fact that Ableton Live runs on ARM-based macs these days means we can assume that if there were any parts of the code that did rely on optimised x86/x86-64 specific instructions, work was already done previously to move beyond such specific code, and that wont need to be repeated (unless Apple happened to offer somewhat automatic conversion of this stuff). We would get another demonstration of this if the world of Windows ARM was moving at blistering pace with fast adoption rates and a large percentage of Windows machines switching to ARM as a no brainer, but for now thats not really the situation so there isnt the same pressure to offer an ARM Windows version of Live for consumers at rapid pace.

I'm well aware of the complications of the GUI side of things per OS, which is why I mentioned 'minus GUI' when discussing their Linux version. And its certainly good news that they've already done the work to make a version of Ableton Live that works with the Linux OS when it comes to things like audio system layers of that OS. And due to max4live support in standalone Push, we already know that if any heavy work were required to make the necessary parts of max work on Linux, this has already been done.

I'm unwilling to make assumptions about how much work the Linux port actually was, or whether any x86/x86-64 specific code still exists in this version. I would want to see the code for myself to do that. And since Ableton Live is nearly 22 years old, I dont want to make assumptions about what old practices might have lingered on as legacy baggage from those days, how much of that legacy has already been eliminated in recent years, how much could in theory still remain.

I would still be inclined to think that the much of the question of feasibility of future ARM support will boil down to the state of ARM compatibility in the 3rd party hardware design, 3rd party libraries, drivers etc. The stars might all align nicely if the time comes where they want to do this, but it would only take one small area where issues remained for the viability to be hampered or for additional effort to work around any problem area to be required.

Personally I would have been happier if the standalone Push 3 had been ARM-based from the beginning, but relying on x86/x86-64 to start with was not anything like enough to put me off getting one. I'll be very happy if they are able to switch to ARM in future, I will celebrate that news big time, but I make no assumptions and even if the upgrade path of the Push 3 that they actually deliver over its lifetime proves to be limited, I am still happy with the device as is.

[subnoize]

Maybe wasn't worth the extra hassle for shaving a few milliseconds of latency?

Actually, that latency would be the chipset on the PCB (the topic of this thread, the NUC).

[subnoize]

I dont think thats actually incompatible with my point...

I understand this is all voodoo to you. It's not something to be ashamed of. I spent 35 years getting here. I don't expect you to learn this overnight.

How Ableton have dealt with this side of the code for the Linux version is unknown to me, since they obviously cannot make use of Apple APIs and Apples own ARM stuff for that.

ARM is ARM, has zero to do with Apple. Apple's customization of lanes and cores, etc has NOTHING to do with the instruction set in the ARM chips.

Let us get a few points out of the way; Intel has an instruction set which is widely known and understood. It is a CISC based chip. ARM is a widely understood instruction set and is RISC based. Implementation of OS would touch supporting chipsets but the application would NOT.

OK, we have established that Ableton is not tied to a PCB with a hard soldered i3 chip on it (as opposed to a socketed and larger module). We have also established that their code base is large and diverse with an obvious and well defined cross-platform core (we know this because they support MacOS, Windows and now Linux. The Push 3 is based around a USB 3 hub and the connection between the Push 3 and the SBC is in fact USB just like if you were using an external computer.

I am not worried about my investment.

[elbows]

I understand this is all voodoo to you. It's not something to be ashamed of. I spent 35 years getting here. I don't expect you to learn this overnight.

It is not all voodoo to me. The exact extent of my knowledge varies depending on exactly what area of detail we are getting into.

ARM is ARM, has zero to do with Apple. Apple's customization of lanes and cores, etc has NOTHING to do with the instruction set in the ARM chips.

Let us get a few points out of the way; Intel has an instruction set which is widely known and understood. It is a CISC based chip. ARM is a widely understood instruction set and is RISC based. Implementation of OS would touch supporting chipsets but the application would NOT.

That misses my point and was not my claim. My claim was only about the tools that Apple made available that happened to make porting of Apple API etc specific parts of the code of the mac version of Ableton Live and every other application fairly trivial for developers when it came to them being able to offer versions of their apps that ran natively on Apple arm-based systems. I know thats not the whole story of porting though.

For example I am pretty familiar with the Apple porting guide ( https://developer.apple.com/documentati ... le-silicon ) and some of the things it lists as issues to consider are the sort of things I was hinting at. Since I dont have access to Abletons code, I cannot claim to know how many of these issues they had to deal with or how much engineering effort was required on their part in order to deliver ARM support for the Apple platform version of Live. Clearly some aspects of work that may need to have been done should be reuseable when it comes to offering Live for ARM support on other operating systems in future (eg if there was any x86/x86-64 specific code of certain types), but I still cannot make assumptions in areas such as 3rd party libraries used on other operating systems, which is one of the reasons I keep referring to those.

The Push 3 is based around a USB 3 hub and the connection between the Push 3 and the SBC is in fact USB just like if you were using an external computer.

Well sort of, I suppose it depends quite how much of the internals you consider to be the SBC. Many aspects of the hardware connect to the internal computer side using USB, which is indeed quite predictable and manageable, these are indeed peripheral aspects. However Im not convinced that its fair to consider that the Compute Element module that is user-replaceable really counts as being the entire SBC. Its a big chunk of it but to offer one obvious example the storage is separate, its not on the same single board/module, there is at minimum another board which handles these other buses which are used to connect to storage etc. USB is not the only bus that connects the Compute Element module to these other parts, only to the more peripheral hardware. There are probably other examples that I would not speak with authority on, but the details about every pin on the compute element module offers strong clues about what some of those are. If you want to consider that all of those parts together count as the SBC then fine, but actually we dont get to replace all of those via a future user upgrade of the Compute Element module alone, so the 'single' part of the term SBC becomes inappropriate, and thats where plenty of my future uncertainty comes from.

At the end of the day it doesnt matter what you think my knowledge level is, or how many years your career spans. All that actually matters is whether anybody will actually in future deliver a module that can be used as a drop-in replacement for the Compute Element initially used in the Push 3, and whether its available on commercial terms that are acceptable to Ableton. There is a difference between 'could in theory' and actually will, there are a range of theoretical technical and commercial factors that will impact on whether this actually needs to happen, when that would be, and whether it will actually happen for the Push 3 in particular. And theres more than one theoretical option. Maybe other existing later generations of Intel-based modules already work or will be made to work (some degree of certainty that the next generation or two after the 11th gen will, at least at the superficial level using publicly available Intel documentation). Maybe future ASUS generations of Compute Element modules will be entirely compatible, maybe they will start to diverge. Maybe there will be ARM options, maybe there wont. And there are potential workarounds depending on Abletons priorities and commitment levels when the time comes. For example even if there were some tedious show-stopping issues with compatibility of the carrier-board side of the hardware design, they could choose to rework that aspect of the Push 3, although whether they would then offer replacement parts for existing users, as opposed to something they could just use to create a revision so they can continue making new units would remain to be seen. They certainly shouldnt need to go right back to square one on the drawing board when it comes to the more peripheral (USB) aspects of the Push 3 hardware, but thats not the whole story, and is not the area of the hardware that has driven this thread.

If I sit around pondering the future of the Push 3 then what matters far more than all of this is that it a commercial success on an ongoing basis. Because then it would be much more likely that they could justify the effort required to workaround any issues that might arise. I am quite comfortable with the uncertainties of the future, with the myriad variables beyond my knowledge or ability to predict. I am a happy Push 3 user who hopes it has a great future ahead of it, and who has no predictions to offer in that regard. And I would not have expected Ableton to feel the need to offer highly detailed reassurances about the issues raised in this thread, not unless they determined that speculation was eroding consumer confidence in the product to the extent that its commercial viability was being notably affected.

[[jur]]

Since it's starting to smell like some ego fight might soon be in the pipeline, I have to put on my cop's hat and remind you to please keep it respectful and humble so this discussion can live on.
Thanks.