The No.1 Website for Pro Audio
CEM, SEM, SSM... DSP? 56K and the future?
Old 21st January 2020
  #1
CEM, CoolAudio, SSM... DSP? 56K and the future?

This is a ramble, so feel free to ignore - a bit of train-of-thought.

We have recreations of classic ICs now - SSM, CEM, [strike]SEM[/strike] and so forth families held in high regard, and the bones of so many classic instruments, yet the post-ASIC era seems to be less certain. Maybe it's all too recent - but the Motorola DSP is coming to the end of life, and maybe that will mean the end of a LOT of hardware.

What kicked this off was writing a bit about the Novation Circuit, challenging the 'Nova class' synthesizer phrase that gets thrown around a lot. It's a good synth - but it's not the same engine as a Nova, or even Mininova. Which lead me to thinking 'what are the resources on hand in a Circuit/Nova chip'.

So I looked at the reissue Nova voice cards on sale on eBay. Six shiny 56362 DSPs on a card, providing 24 voices.

"What's in a Circuit?". Can't find a clear picture online, but it looks like one 56K DSP in the middle of the board. It could be something entirely different...

But those 56K DSP-based synths go back a long way. The Peavey DPM, Nord Modular (and Lead?), Access Virus, presumably the Nova (though I think the 56362 post-dates Novas); in fact, the 56K DSP family is coming up for end of availability in a few years, not just development - and I have absolutely no idea how many more synths used that architecture, but I bet it's a lot of them.

https://synthmorph.com/blogs/news/ac...-amp-virus-ti3

This charts some of the issues around the 56K, but I feel like it skips one element - that actually, the Virus (and Nova, and so forth) are just fine - they don't need to keep moving, they're instruments. So the need to make a bigger, better Virus TI2 is really more a question of either making a smaller, more accessible and affordable Virus, or continuing to make a new Virus for people who want that sound, or need to replace broken, older hardware.

So rather than abandoning the years of learning that have gone into all the Motorola 56K-based synthesizers... Could a new company keep producing 56K architecture chips? And in the future, will forum experts pontificate on the DSP sound vs FPGA vs soft-DSPs on multi-core ARM architectures?

What's the point of this? Maybe there isn't one, other than to recognise that the little chip that made the Atari Falcon more than just a 32-bit Atari ST, the NeXT more than a glorified Unix box, and countless flexible, rapidly developed and groundbreaking synthsizers possible is - compared to all those analogue ones - relatively unrecognised.

And that's before we question who it was that developed the original algorithms we heard of modelled components...

Last edited by RichardTK; 22nd January 2020 at 04:08 PM..
Old 21st January 2020
  #2
Old 21st January 2020
  #3
Gear Nut
My personal 56K craze started out with the Falcon030. Though my two Falcons aren't around anymore, I'm counting at least 39 - yes, THIRTY NINE! - 56K chips still in active use here! That's 30 chips in seven Nord Modulars, five on a single Korg Oasys PCI card and four inside an older 56K based Symbolic Sound Kyma unit. And there might still be a few more hiding somewhere...

I really feel I need to get on with my life! ;-)
Old 21st January 2020
  #4
Lives for gear
 
monomer's Avatar
 

I don't think this is a viable idea because, unlike the analog chips you mentioned, a DSP doesn't actually contribute anything substantial to the actual sound.
All the algorithms could be run in higher quality on a much cheaper chip these days. If you're a purist you could emulate all the arithmetic quirks and still be cheaper off than using these chips.
IMO there is no contest against current off-the-shelve components.
Old 21st January 2020
  #5
Lives for gear
 
daviddever's Avatar
Is there an argument to be made for a 56K-on-FPGA emulation / implementation?
Old 21st January 2020
  #6
Lives for gear
 
monomer's Avatar
 

Quote:
Originally Posted by daviddever View Post
Is there an argument to be made for a 56K-on-FPGA emulation / implementation?
IMO only if you want to emulate the old algorithms without porting them. For new stuff it makes no sense to me.
Old 21st January 2020
  #7
Quote:
Originally Posted by monomer View Post
I don't think this is a viable idea because, unlike the analog chips you mentioned, a DSP doesn't actually contribute anything substantial to the actual sound.
All the algorithms could be run in higher quality on a much cheaper chip these days. If you're a purist you could emulate all the arithmetic quirks and still be cheaper off than using these chips.
IMO there is no contest against current off-the-shelve components.
So in the same way that we've seen these classic synth chips, circuit designs recreated...

What's become of the original work that went into these algorithms? Were they building blocks in an SDK, or original code, original creations? I'm absolutely on board with the idea that the theory and signal flow could move to entirely different hardware - but at the same time, intrigued that one DSP is so prevalent, in synths that are arguably of very different capabilities and characters.
Old 21st January 2020
  #8
Lives for gear
 
monomer's Avatar
 

Quote:
Originally Posted by RichardTK View Post
So in the same way that we've seen these classic synth chips, circuit designs recreated...
Yes, except you don't actually need the original chips.
It's not the DSP chip that dictates the sound, it's the algorithms that are run on it.


Quote:
What's become of the original work that went into these algorithms?
Well, the algorithms are still valid. It's only the implementation that is specific to these chips. Point in case, Clavia made a G2 demo that runs on x86. No need for the DSP chip.

Quote:
Were they building blocks in an SDK, or original code, original creations?
A lot of it is going to be based on field knowledge. For instance, some time ago i implemented a relatively simple LPF filter from a research paper in reaktor and it sounded eerily similar to the filter in the nord modular. Especially when i lowered the samplerate.
So it's definitely not all original algorithms. The implementation could be tho.
But generally it's difficult to say what the exact source of the algorithm is. IN code it's too easy to change some things up and 'do it your own way'.

Quote:
I'm absolutely on board with the idea that the theory and signal flow could move to entirely different hardware - but at the same time, intrigued that one DSP is so prevalent, in synths that are arguably of very different capabilities and characters.
I don't think it's that surprising. It was all about 'bang for buck'. These DSP's were on the market, available and relatively cheap for the DSP power they delivered. But that was over 20 years ago. And you have to remember that there simply wasn't all that much choice in those days if you wanted/needed a particular amount of DSP. That's why you see devices having multiple of these chips.
Then there is (indeed) familiarity with implementing the architecture, tooling and programmer skills and all that kind of stuff that makes people decide for one platform over another.

But in the end it probably just made economic sense to use these chips.
And these things work weirdly. The more a chip is used the more chance it will have for staying on the market for cheap and the more people use it, the more libraries are developed for it, the more books are written about it, etc. It kindof becomes an industry standard for solving particular problems. Until it stops being financially viable and the market changes over to other platforms.
Old 21st January 2020
  #9
Lives for gear
 
wagoo's Avatar
I wonder if Clavia wrote their OS in some higher level language that then could be compiled into 56k machine code though? If it's so easy then you have to wonder why Access are still using those chips in the Virus TI and Kemper Profiler.. we know they write their stuff in pure machine code against that DSP family

It reminds me a bit of emulators for old ASIC based systems. Usually one can be knocked up to run the old machine code, but to iron out all the little quirks of the hardware it usually ends up taking a lot more resources to get all the timings accurate and such. Look at how much CPU something like snes9x takes vs bsnes

Related: https://arstechnica.com/gaming/2011/...snes-emulator/
Old 21st January 2020
  #10
Gear Addict
 

Quote:
Originally Posted by RichardTK View Post
This charts some of the issues around the 56K, but I feel like it skips one element - that actually, the Virus (and Nova, and so forth) are just fine - they don't need to keep moving, they're instruments. So the need to make a bigger, better Virus TI2 is really more a question of either making a smaller, more accessible and affordable Virus, or continuing to make a new Virus for people who want that sound, or need to replace broken, older hardware.
Well, the Virus algorithms were impressive when they were first developed (over 20 years ago). Circuit emulation has improved since then (for instance, with zero-delay feedback filters), so if I were buying a new synth a Virus would not be a candidate now.
Old 21st January 2020
  #11
Gear Nut
Quote:
Originally Posted by monomer View Post
Well, the algorithms are still valid. It's only the implementation that is specific to these chips. Point in case, Clavia made a G2 demo that runs on x86. No need for the DSP chip.
I believe the G2 Demo is actually based on a 56K emulator provided by Freescale.
Old 21st January 2020
  #12
Lives for gear
 
BobTheDog's Avatar
 

CMU had a fpga 56k implementation years ago, I think it wasn't a full implementation but maybe someone took this further.

As Monomer says though, what's the point. The algorithms are what are important.
Old 21st January 2020
  #13
Gear Nut
Quote:
Originally Posted by monomer View Post
Yes, except you don't actually need the original chips.
It's not the DSP chip that dictates the sound, it's the algorithms that are run on it.
Older DSP's, such as the 56K series, generally run at a steady (fully predictable) one instruction per execution cycle rate and as there are also no cache memories and no time sharing and resource hogging OS running, there's no need for buffering (i.e. block based processing) and feedback connections throughout the system (inside a single DSP) can be made with only a single sample of delay. Integer maths also contribute to the overall sound.

56K assembler used to be the format in which much of the audio DSP codebase was written. And many of the algorithms were closely tied to the 56K architecture. These days the majority of the DSP codebase (in the world) is probably written in C. But I can imagine some companies having stuck with the 56K because of the old codebase and because the old DSP tech was never really superseded by anything that could be thought of as being "the same but better".

Audio processing generally parallelizes really well and future computation platforms derived from GPU tech could potentially cater really well for audio DSP needs. But I'm not sure who'd have the bucks BIG enough to push the tech in that direction. (I fear that'd probably have to be the arms industry, if anyone.) Current (GP)GPU technology - to my knowledge - is not a good fit for realtime audio DSP - because of various reasons. FPGA's hold a lot of promise too - especially for high sample rate DSP - but the current "programming" paradigm is perhaps a bit of a challenge for many developers... Maybe new high level programming tools and further advances in hardware tech could change the situation?
Old 22nd January 2020
  #14
Lives for gear
 
monomer's Avatar
 

Quote:
Originally Posted by Yammy GS1 View Post
I believe the G2 Demo is actually based on a 56K emulator provided by Freescale.
Haha, seriously? Ok, that explains some things.
It kindof does show how underpowered these chips actually are compared to pc's. Even in those days it didn't impact the CPU all that much. And that was apparently including the overhead of the emulator.
Old 22nd January 2020
  #15
Lives for gear
 
monomer's Avatar
 

Quote:
Originally Posted by wagoo View Post
I wonder if Clavia wrote their OS in some higher level language that then could be compiled into 56k machine code though? If it's so easy then you have to wonder why Access are still using those chips in the Virus TI and Kemper Profiler.. we know they write their stuff in pure machine code against that DSP family

It reminds me a bit of emulators for old ASIC based systems. Usually one can be knocked up to run the old machine code, but to iron out all the little quirks of the hardware it usually ends up taking a lot more resources to get all the timings accurate and such. Look at how much CPU something like snes9x takes vs bsnes

Related: https://arstechnica.com/gaming/2011/...snes-emulator/
Well, if it's done in assembly then porting would be a major problem of course. Probably lots of hand-tuned optimizations and such to get the most out of these chips.

About the snes emulator thing, if i understand correctly that is mostly due to the fact that there are several components in that machine that run somewhat asynchronously. Getting the timing right on where these subsystems 'meet' requires an overall higher 'step' rate.
In a synth tho i think all the work is done on the DSP's which all run at the same clock rate and in that respect allows a more transparent emulation.
Possibly the handling of the UI could run separately from the DSP synth core, but i don't think that it would be of any consequence if that didn't match up perfectly with the synth engine.
Old 22nd January 2020
  #16
Lives for gear
 
monomer's Avatar
 

Quote:
Originally Posted by Yammy GS1 View Post
Older DSP's, such as the 56K series, generally run at a steady (fully predictable) one instruction per execution cycle rate and as there are also no cache memories and no time sharing and resource hogging OS running, there's no need for buffering (i.e. block based processing) and feedback connections throughout the system (inside a single DSP) can be made with only a single sample of delay. Integer maths also contribute to the overall sound.
You don't actually need to have any buffering on a modern general purpose system except maybe on the peripherals (control inputs and audio output). If You could write your code in a way that operates on a single sample throughout. Of course you'll still get interrupted by the OS and such. You can also do integer math, tho i think the 56K's had a particular bit depth? (multiples of 24 bits or something?)

Quote:
56K assembler used to be the format in which much of the audio DSP codebase was written. And many of the algorithms were closely tied to the 56K architecture.
Sure, makes perfect sense. 56K was a thing back then.

Quote:
These days the majority of the DSP codebase (in the world) is probably written in C. But I can imagine some companies having stuck with the 56K because of the old codebase and because the old DSP tech was never really superseded by anything that could be thought of as being "the same but better".
I don't agree. These days i have heard a lot of synths and plugins that sound much better than ye ol VA synths, quality wise. I'm not speaking of how original the algorithms are per se. But you know, some DSP processes do really sound better at higher bit depths and/or higher sample rates. Floating point math also helps in places. And IMHO these 90's VA synths do have a particular 'digitalness' to them that i think is directly related to the algorithms that were formulated in those days and the limitations of the hardware they executed on.
And i also think that the increase in processing power allowed for better algorithms to be executed. I mean, good luck running U-He stuff on a 56K.

Quote:
Audio processing generally parallelizes really well and future computation platforms derived from GPU tech could potentially cater really well for audio DSP needs. But I'm not sure who'd have the bucks BIG enough to push the tech in that direction. (I fear that'd probably have to be the arms industry, if anyone.) Current (GP)GPU technology - to my knowledge - is not a good fit for realtime audio DSP - because of various reasons. FPGA's hold a lot of promise too - especially for high sample rate DSP - but the current "programming" paradigm is perhaps a bit of a challenge for many developers... Maybe new high level programming tools and further advances in hardware tech could change the situation?
Yeah, GPU's suck in many ways. For one, they suck so much power out of the system that it starts influencing the sound. If it's active, i can hear my GPU whining over the audio om my audio interface (RME on USB). It's really brutal. If it's not active i get a more than decent s/n ratio.
Another thing with GPU's is that it's designed to process stuff in large chunks so fine time control goes out the window.

Not too sure about the parallelization tho. Ok, things like polyphony are trivial to parallelize. But a lot of algorithms are very state-like. And that is hard if not impossible to parallelize.

FPGA's are great but also a steep hurdle. But you see manufacturers taking it in recent years. I think this is great!

But i also think that there is a lot of merit in using general purpose CPU's these days. They are very powerful. As i said, some of the best sounding synths IMO are actually plugins.
Old 22nd January 2020
  #17
Gear Nut
 

Quote:
Originally Posted by Yammy GS1 View Post
Older DSP's, such as the 56K series, generally run at a steady (fully predictable) one instruction per execution cycle rate and as there are also no cache memories and no time sharing and resource hogging OS running, there's no need for buffering (i.e. block based processing) and feedback connections throughout the system (inside a single DSP) can be made with only a single sample of delay.
That hardly matters when other things are just so much more powerful.

Quote:
Originally Posted by Yammy GS1 View Post
Integer maths also contribute to the overall sound.
PC and ARM CPUs (and some other DSPs) have no problem with using 24 bit integers if you want.

(The whole "Nord Modular 2 demo running on a 56K emulator" sinks those augments as well)

Quote:
Originally Posted by Yammy GS1 View Post
the old DSP tech was never really superseded by anything that could be thought of as being "the same but better".
There is plenty of DSPs that leave the 56K in the dust.

Quote:
Originally Posted by monomer View Post
For one, they suck so much power out of the system that it starts influencing the sound. If it's active, i can hear my GPU whining over the audio om my audio interface (RME on USB). It's really brutal. If it's not active i get a more than decent s/n ratio.
That is caused by the inductors on the graphics card vibrating due to power supply ripple (small AC voltage overlaid on the the DC supply), I had the same problem with my graphics card putting out noise (when under load) not only on any electrically connected audio outputs, but also from the inductors making a sound themselves. Switching to a PSU with lower 12 volt ripple fixed that.
Old 22nd January 2020
  #18
Gear Nut
Quote:
Originally Posted by monomer View Post
You don't actually need to have any buffering on a modern general purpose system except maybe on the peripherals (control inputs and audio output). If You could write your code in a way that operates on a single sample throughout. Of course you'll still get interrupted by the OS and such.
I wonder how much less efficient it is to process the signal unbuffered compared to block based processing on a modern CPU under a regular desktop OS? I haven't done a lot of realtime ITB audio in my life, but I recently got myself a copy of Reaktor and have been wondering if it might be possible to run it with zero buffers? Many of my 56K based creations rely on heavy (ab)use of single sample feedback connections. I'd love to be able to implement similar systems in Reaktor!

Quote:
Originally Posted by monomer View Post
You can also do integer math, tho i think the 56K's had a particular bit depth? (multiples of 24 bits or something?)

I don't agree. These days i have heard a lot of synths and plugins that sound much better than ye ol VA synths, quality wise. I'm not speaking of how original the algorithms are per se. But you know, some DSP processes do really sound better at higher bit depths and/or higher sample rates. Floating point math also helps in places. And IMHO these 90's VA synths do have a particular 'digitalness' to them that i think is directly related to the algorithms that were formulated in those days and the limitations of the hardware they executed on.
And i also think that the increase in processing power allowed for better algorithms to be executed. I mean, good luck running U-He stuff on a 56K.
Sorry I meant that both, not having to do the processing in blocks and having to do all the processing in integer math, affect the overall sound - the latter being A RESTRICTION compared to more recent systems with floating point capabilities.

And I fully agree on newer algorithms run on vastly more powerful modern CPU's sounding better than the stuff that was possible on old 56K based hardware! By "the same but better" I meant that in an ideal situation we'd now be using DEDICATED DSP's as powerful as the most powerful CPU's of today and specialized sound computation accelerators as fast and as deeply parallelized as the latest and greatest GPU hardware currently available. Instead we have generic CPU's on generic PC motherboards and generic operating systems. (Yeah OK, so go ahead and create your own baremetal OS for your synth - a year later the same motherboard model is no longer available!)

Quote:
Originally Posted by monomer View Post
Not too sure about the parallelization tho. Ok, things like polyphony are trivial to parallelize. But a lot of algorithms are very state-like. And that is hard if not impossible to parallelize.
Individual algorithms may not be parallelizable (perhaps some are?), but in a typical (virtual) studio situation or inside any average synth audio (data) is being processed (at least conceptually) concurrently in several stages - similar to several branching factory assembly lines running in parallel. Data flow processing in general is highly parallelizable.

Quote:
Originally Posted by monomer View Post
FPGA's are great but also a steep hurdle. But you see manufacturers taking it in recent years. I think this is great!
One of these days I'll roll up my sleeves up and start learning FPGA - errr - stuff? Seems to me like that might be the right investment to make if one's into designing hardware based (digital) synths these days. It's just that the "programming" paradigm is "slightly" different from anything I'm previously familiar with...
Old 22nd January 2020
  #19
Gear Nut
Quote:
Originally Posted by NamesAreAPain View Post
That hardly matters when other things are just so much more powerful.
If processing power is all that matters, sure. I'm pretty certain even my 8 MHz Atari still has a better response time than a new Windows 10 based machine - a quality that's pretty nice for things like MIDI for example!

Quote:
Originally Posted by NamesAreAPain View Post
There is plenty of DSPs that leave the 56K in the dust.
I'm sure there are. But if I was (and I kind of am) in a situation where I needed to pick a DSP hardware platform for my new synth, which current architecture would you suggest I should choose - and why?
Old 22nd January 2020
  #20
Lives for gear
 
daviddever's Avatar
Quote:
Originally Posted by Yammy GS1 View Post
If processing power is all that matters, sure. I'm pretty certain even my 8 MHz Atari still has a better response time than a new Windows 10 based machine - a quality that's pretty nice for things like MIDI for example!



I'm sure there are. But if I was (and I kind of am) in a situation where I needed to pick a DSP hardware platform for my new synth, which current architecture would you suggest I should choose - and why?
Arm Cortex M4F, hands-down.
Old 22nd January 2020
  #21
Gear Nut
 

Quote:
Originally Posted by Yammy GS1 View Post
If processing power is all that matters, sure. I'm pretty certain even my 8 MHz Atari still has a better response time than a new Windows 10 based machine - a quality that's pretty nice for things like MIDI for example!
There is no guarantee that a DSP system would have noticeable lower real world latency, which is the only thing that you listed that has any bearing on the end user.

If you think that non DSP56K CPUs and DSPs are somehow not up to the task you clearly have not seen synths and workstations from Korg (e.g Wavestate uses ARM, Kronos is an old PC), Nord (Lead 4, A1 and likely Wave 2 use SHARC), Roland (System 1 and some of Boutiques use the Roland ESC2 DSP, System 8, Jupiter X and XM use the BMC DSP), Audiothingies Micromonsta (ARM), John Bowen Solaris (SHARC) ect.


Quote:
Originally Posted by Yammy GS1 View Post
I'm sure there are. But if I was (and I kind of am) in a situation where I needed to pick a DSP hardware platform for my new synth, which current architecture would you suggest I should choose - and why?
The fact that DSP56K is pretty much end of life, makes any so called advantages of it irreverent to new synth designs.

There is plenty of info on DSPs online if you search, e.g https://dspconcepts.com/sites/defaul...8_beckmann.pdf shows an oldish ARM Cortex A15 (while running an OS!) spanking a whole bunch of dedicated DSPs and https://www.ti.com/lit/wp/sprabn8a/sprabn8a.pdf does have benchmarks between a whole lot of DSPs (but is Ti marketing material).
Old 22nd January 2020
  #22
Lives for gear
 
eXode's Avatar
 

Quote:
Originally Posted by RichardTK View Post
This is a ramble, so feel free to ignore - a bit of train-of-thought.

We have recreations of classic ICs now - SSM, CEM, SEM and so forth families held in high regard, and the bones of so many classic instruments, yet the post-ASIC era seems to be less certain. Maybe it's all too recent - but the Motorola DSP is coming to the end of life, and maybe that will mean the end of a LOT of hardware.
FYI, there is no SEM ic. The SEM, or synthezier expander module, is a synthesizer made by Tom Oberheim.

CEM & SSM = various ICs

Old 22nd January 2020
  #23
Lives for gear
 
usedtohaveajuno's Avatar
Quote:
Originally Posted by Yammy GS1 View Post

One of these days I'll roll up my sleeves up and start learning FPGA - errr - stuff? Seems to me like that might be the right investment to make if one's into designing hardware based (digital) synths these days. It's just that the "programming" paradigm is "slightly" different from anything I'm previously familiar with...
AWS has FPGA instance types now, with all the design licences built in - go for it!

My big sister worked on the 56000 - we had the big Motorola fab in Scotland

For my CompSci honours project at Uni in 1993 she arranged for me to get a bunch so I could build a hardware sampler, but it was far more work than I expected and I had to abandon it and design a compiler instead
Old 22nd January 2020
  #24
Gear Maniac
I think ARM is the future for more affordable digital synths when the cost of a custom ASIC or FPGA can't be justified. Yes, this essentially makes them a "Raspberry Pi with keys", but the latest generations of ARM chips are powerful enough, where as the old DSP chips are actually quite weak by today's standards, even when dealing with the specialized maths where dedicated DSP's used to shine. Latency and reliability mostly comes down to software optimizations.
Old 22nd January 2020
  #25
Gear Nut
 

ELK Audio OS

Quote:
Originally Posted by NamesAreAPain View Post
There is no guarantee that a DSP system would have noticeable lower real world latency, which is the only thing that you listed that has any bearing on the end user.

If you think that non DSP56K CPUs and DSPs are somehow not up to the task you clearly have not seen synths and workstations from Korg (e.g Wavestate uses ARM, Kronos is an old PC), Nord (Lead 4, A1 and likely Wave 2 use SHARC), Roland (System 1 and some of Boutiques use the Roland ESC2 DSP, System 8, Jupiter X and XM use the BMC DSP), Audiothingies Micromonsta (ARM), John Bowen Solaris (SHARC) ect.



The fact that DSP56K is pretty much end of life, makes any so called advantages of it irreverent to new synth designs.

There is plenty of info on DSPs online if you search, e.g https://dspconcepts.com/sites/defaul...8_beckmann.pdf shows an oldish ARM Cortex A15 (while running an OS!) spanking a whole bunch of dedicated DSPs and https://www.ti.com/lit/wp/sprabn8a/sprabn8a.pdf does have benchmarks between a whole lot of DSPs (but is Ti marketing material).
Today there is a very attractive alternative: the ELK Audio OS operating system https://elk.audio/audio-os/ which uses CPU General purpose ARM and INTEL (https://elk.audio/developer/), which guarantees 1ms latency round-trip on supported Hardware and allows the reuse of years and years of C and C ++ code used for VST and Rack Extension https://elk.audio/news/. Among the various "boards" compatible also the excellent i.MX8M with four ARM A53 cores https://elk.audio/elk-on-the-i-mx8m-mini/
Old 22nd January 2020
  #26
Lives for gear
 
daviddever's Avatar
Another factor that might be worth considering: the Motorola / Freescale 56K3 "Symphony" family was largely oriented toward home theater / consumer electronics applications (note the double-D Dolby logo), and were also repurposed for the PMD-200 digital filter IC (used in many late-90s / early-00s CD players and DACs). This alone would have made these far less expensive (by volume) to manufacture.
Old 22nd January 2020
  #27
Quote:
Originally Posted by monomer View Post
Yes, except you don't actually need the original chips.
It's not the DSP chip that dictates the sound, it's the algorithms that are run on it.
I think you're missing the sarcasm around that original thread (not this post) - I'm aware that in this case the software is the magic, but it came out of the softsynth debates and things that go on forever in forums when often, the same libraries will be used.

But there's some truth too, in that the feel of the games written on old hardware, the feel of emulations... there's always a perception it's not the same. I think there will be aspects of the 56K that lead to certain ways of thinking, or solutions, that may not crop up with more powerful/different solutions. Ultimately audio's all about the imperfections, the stuff you can't clone endlessly, for many people - the quirks in the performance.

I'm actually really enjoying where this thread has gone. And yeah, SHARC needs one too - I believe SHARC will be heading away eventually - and I remember those sorts of chips, SHARC and BlackFin, being used in early digital cameras... I'm fascinated by the way everything comes down to capturing and manipulating waves of energy with electronics.
Old 22nd January 2020
  #28
Quote:
Originally Posted by eXode View Post
FYI, there is no SEM ic. The SEM, or synthezier expander module, is a synthesizer made by Tom Oberheim.

CEM & SSM = various ICs

For some reason, I'm thinking there were three common chip manufacturers for VCOs and VCFs, so SEM popped into my head. It's just another TLA and another IP that people look to recreate...
Old 22nd January 2020
  #29
Quote:
Originally Posted by Benis67 View Post
Today there is a very attractive alternative: the ELK Audio OS operating system https://elk.audio/audio-os/ which uses CPU General purpose ARM and INTEL (https://elk.audio/developer/), which guarantees 1ms latency round-trip on supported Hardware and allows the reuse of years and years of C and C ++ code used for VST and Rack Extension https://elk.audio/news/. Among the various "boards" compatible also the excellent i.MX8M with four ARM A53 cores https://elk.audio/elk-on-the-i-mx8m-mini/
I'm very interested in these - when I can afford to explore, I will be doing so.
Old 22nd January 2020
  #30
Gear Nut
 

Quote:
Originally Posted by RichardTK View Post
I'm very interested in these - when I can afford to explore, I will be doing so.
The code for Elk Pi Hat for Raspberry Pi is open source: there is already 400+ pre-built open-source plugins ready to run! Elk dev-kit/.
Here the Elk Community plugins repository Elk Community with virtual like Dexed, OB-Xd, juicy sf plugin (sf2 with fluidsynth),....
๐Ÿ“ Reply

Similar Threads

Thread / Thread Starter Replies / Views Last Post
replies: 61 views: 6895
Avatar for Doktorfuture
Doktorfuture 17th December 2009
replies: 21 views: 6410
Avatar for Zentrails
Zentrails 24th March 2013
replies: 154 views: 17774
Avatar for Kubase
Kubase 31st July 2016
replies: 3188 views: 109351
Avatar for JohnnyP702
JohnnyP702 16 hours ago
Topic:
Post Reply

Welcome to the Gearslutz Pro Audio Community!

Registration benefits include:
  • The ability to reply to and create new discussions
  • Access to members-only giveaways & competitions
  • Interact with VIP industry experts in our guest Q&As
  • Access to members-only sub forum discussions
  • Access to members-only Chat Room
  • Get INSTANT ACCESS to the world's best private pro audio Classifieds for only USD $20/year
  • Promote your eBay auctions and Reverb.com listings for free
  • Remove this message!
You need an account to post a reply. Create a username and password below and an account will be created and your post entered.


 
 
Slide to join now Processing…
๐Ÿ–จ๏ธ Show Printable Version
โœ‰๏ธ Email this Page
๐Ÿ” Search thread
๐ŸŽ™๏ธ View mentioned gear
Forum Jump
Forum Jump