electro-music.com   Dedicated to experimental electro-acoustic
and electronic music
 
    Front Page  |  Articles  |  Radio
 |  Media  |  Forum  |  Wiki  |  Links  |  Store
Forum with support of Syndicator RSS
 FAQFAQ   CalendarCalendar   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   LinksLinks
 RegisterRegister   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in  Chat RoomChat Room 
 Forum index » Clavia Nord Modular » Nord Modular G2 Discussion
Technical DSP question
Post new topic   Reply to topic Moderators: Nord Modular Editors
Page 1 of 1 [10 Posts]
View unread posts
View new posts in the last week
Mark the topic unread :: View previous topic :: View next topic
Author Message
marioisaac



Joined: Jan 24, 2016
Posts: 26
Location: Panama

PostPosted: Fri Jun 24, 2016 5:03 pm    Post subject: Technical DSP question Reply with quote  Mark this post and the followings unread

Hello people,

I have an inquiry regarding DSP.

As I understand DSP-chips can perform one calculation at a time; what exactly does this mean?

e.g. Let's say I set the sample rate of the G2 to run at 96KHz.
On the G2 (because it uses DSP), each module operation has to be realized one at a time: what does one at a time mean? One calculation per sample? or can the system perform multiple calculations (one at a time) in the time span between each sample?

How can all modules in a patch output samples at the same time, if DSP can only perform calculations one at a time?

So strictly speaking, in a DSP system, we (and modules receiving input information from other modules), are always listening to the past. We are listening to the result of operations performed upon the input values of all modules in the system in the previous sample?

Or if there are 100 modules with 100 outputs, are we listening to a 100 samples delayed signal?

I am trying to zoom in time here to get a clear vision of how the system works. Any help is appreciated.

Thank you,
Back to top
View user's profile Send private message
Blue Hell
Site Admin


Joined: Apr 03, 2004
Posts: 22884
Location: The Netherlands, Enschede
Audio files: 239
G2 patch files: 319

PostPosted: Sat Jun 25, 2016 1:57 am    Post subject: Reply with quote  Mark this post and the followings unread

One at a time - yes, but it can do that very quickly, so in a given time span it can do several operations. The results of those operations are not gone once performed, but they can be stored for some more processing later on.

A sample rate of 96 kHz means that the sound to be made is to be sent to the output once every 1 / 96000 s, or once every 10.4 micro seconds. And that is the time span available for the processor to calculate one sample for the sound.

Now let's assume that the processor can do one operation at a time, but that it can do so at a rate of 96 MHz (which is about the actual speed it runs at ... more or less .. in orders of magnitude). This means that it is 1000 times as fast as the audio rate, and that in turn means that in those 10.4 micro seconds it can do 1000 operations.

Some modules are very simple to calculate, and in fact would only need one or two operations for each sample, while others may need tens of operations to be performed for each sample. The CPU load of a patch would be percentage of those 1000 that are actually needed for a given patch.

Now the way that a patch is calculated.

Each module in turn will be given time to calculate it's sample (so it performs one to tens of operations then) which will lead to a new output value for that module. This new output value will then be stored in memory at a location that was determined when the patch was compiled. The latter means that any modules which need that output value as their input can pick up that value at a known location.

This means that there is one sample of delay for going trough each module. The total delay in samples of a chain of modules thus is the count of the modules in that chain.

The way that a module is getting calculation time is pretty simple too - the instructions for the operations will be placed (by the patch compiler) one after the other, such that when execution runs out of one module it will then fall into the next one. And then at the end there will be goto start instruction to repeat the process for the next sample. There can be no more that the about 1000 operations in that loop or the calculation would be too slow to produce the next sample in time for the required 96 kHz sample rate.

The input and output modules for a patch, that is where external sound enters and leaves, are a bit special, in that they will have to obtain or deliver their current input / output value from / to the hardware (the DA and AD converter) - which will add a little bit of a delay too.

That is the general idea for how it all works .. hope it helps a bit :-)

_________________
Jan
also .. could someone please turn down the thermostat a bit.
Posted Image, might have been reduced in size. Click Image to view fullscreen.
Back to top
View user's profile Send private message Visit poster's website
marioisaac



Joined: Jan 24, 2016
Posts: 26
Location: Panama

PostPosted: Sat Jun 25, 2016 1:47 pm    Post subject: Reply with quote  Mark this post and the followings unread

It helps a lot Blue Hell!!! Thank you, you are amazing Smile

Now following this string of thoughts, and in order to confirm I got a firm grasp on this concept, let me express and apply to another case what I understood from the previous explanations (correct me if I'm wrong):

Given an actual computer that has a CPU speed of 2.4 GHz, it can do a single operation at a rate of 2.4 GHz (once every 0.42 nano seconds). This means it is 25x faster than the 96 MHz CPU built into the G2 DSP Chips, and it is 25,000x faster than the 96KHz sample rate, so in those 10.4 micro seconds it would be able to perform 25,000 operations.

And if the CPU is a Quad Core, this would mean it can do 4 different operations at a time?
Are the 2.4 GHz cycles distributed between the 4 cores, or each one gets 2.4 GHz, rendering a total speed of 9.6 GHz, therefore giving the possibility to perform 100,000 operations in the span time of 10.4 micro seconds?

In the G2 (given the CPU limitations of the time it was created), each module that has an input connected to the output of another module, goes to the memory location where the output values of the other module are located, to pickup the results from the operations performed upon the previous sample).

With todays processing power, and in general, is the sample latency of Audio Applications dependent upon the number of modules (e.g. 100 modules = 100 samples delay), or instead all modules pickup the output values of other modules (in between the time span of a sample), process them, and get the results ready for the next sample, reducing the overall latency of the system to 1 sample, rather than being dependent upon the number of modules instantiated and being active in the system?

The only benefit that I see results from speeding up this process seems to be reduced latency.
are there any actual sonic possibilities or differences that result from this speed up process?

I am aware that a personal computers would demand CPU resources from other Apps and activities that have nothing to do with DSP. But still there seems to remain much more cycles left for DSP processing demanded by Audio Apps, than a 96 MHz CPU reserved exclusively for DSP.

Back to G2 specifics: are the CPU and Memory capacities of the DEMO equivalent to 1x 96 MHz DSP Chip of the G2 Hardware? or are this capacities considerably inferior in the DEMO?

Thank you,

Last edited by marioisaac on Sat Jun 25, 2016 3:13 pm; edited 1 time in total
Back to top
View user's profile Send private message
Blue Hell
Site Admin


Joined: Apr 03, 2004
Posts: 22884
Location: The Netherlands, Enschede
Audio files: 239
G2 patch files: 319

PostPosted: Sat Jun 25, 2016 2:29 pm    Post subject: Reply with quote  Mark this post and the followings unread

Ah, good ... good questions ... I will post a longer answer later - but before this turns into a ' fact' - the 96 MHz rate I mentioned was not the actual number. I used to know the actual, but I forgot .. anyway its about the right range, and it was used for illustrational purposes only.
_________________
Jan
also .. could someone please turn down the thermostat a bit.
Posted Image, might have been reduced in size. Click Image to view fullscreen.
Back to top
View user's profile Send private message Visit poster's website
marioisaac



Joined: Jan 24, 2016
Posts: 26
Location: Panama

PostPosted: Sat Jun 25, 2016 3:01 pm    Post subject: Reply with quote  Mark this post and the followings unread

Ok, great Smile
Back to top
View user's profile Send private message
Tim Kleinert



Joined: Mar 12, 2004
Posts: 1147
Location: Zürich, Switzerland
Audio files: 7
G2 patch files: 236

PostPosted: Sat Jun 25, 2016 4:03 pm    Post subject: Reply with quote  Mark this post and the followings unread

Blue Hell wrote:
This means that there is one sample of delay for going trough each module. The total delay in samples of a chain of modules thus is the count of the modules in that chain.

Sorry Jan, but I have to correct you here. Smile A chain of modules in the G2 system will have only one sample of delay, just as one single module, as they will be calculated sequentially and pass their result values on to the next module to be calculated within the same 96kHz time frame.

marioisaac wrote:
Or if there are 100 modules with 100 outputs, are we listening to a 100 samples delayed signal?

As stated above, no. Smile All modules in the G2 are calculated simultaneously 96000 times a second. So, eg. a signal processing path that involves 100 processing modules in sequence will not introduce 100 samples of latency, but only one, as their results will be calculated sequentially, and the result will be passed down to the next module, which will be calculated next -all within the 96kHz time frame.

So it only boils down to the sequence in which the modules are being calculated. And the G2 patch compiler is pretty smart in that it first will determine feedback loops and unidirectional strings of modules, and make sure that those are calculated in sequence from first to last module. Besides that, the calculation sequence will follow a "top-down, left-right" scheme pertaining module placement on the editor screen.

So, in basic scenarios, one doesn't have to give all of this a single thought and can just patch away freely. It's only in low-level sample-accurate processes that one has to be aware of these issues in order to make intricate things work as intended. The good news is that the G2 patch compiler is 100% predictable in terms of module calculation order. (Otherwise, all my low-level algorithms wouldn't work at all. Laughing)

Pertaining the discussion of standalone DSP systems versus general-purpose computer CPUs, I'll only go so far as to mention the obvious fact that one is comparing a task-specific professional-grade mission-critical real-time system with a general-purpose consumer-grade and thus non-mission-critical non-real-time-system (being an ecosystem of interrupts). The consequences of this is are manifold, and the relevance of those dependent on user requirements.

(EDIT: Just for clarification, all the above-mentioned calculation speeds of the G2 system pertain its audio-rate (=red cables), which clocks at 96kHz. The G2 system control-rate (=blue cables) clocks at 24kHz. All the considerations pertaining calculation order of modules apply here in the exact same way. (Only caveat is rare situations when control-rate circuits communicate with audio-rate circuits. This can become pretty messy in low-level situations, I'd rather not go down that rabbit hole in terms of explaining right now... Laughing))
Back to top
View user's profile Send private message
marioisaac



Joined: Jan 24, 2016
Posts: 26
Location: Panama

PostPosted: Sat Jun 25, 2016 7:07 pm    Post subject: Reply with quote  Mark this post and the followings unread

Hi Tim,

Thank you for joining the conversation.
Quote:
marioisaac wrote:
Or if there are 100 modules with 100 outputs, are we listening to a 100 samples delayed signal?
As stated above, no. Smile All modules in the G2 are calculated simultaneously 96000 times a second. So, eg. a signal processing path that involves 100 processing modules in sequence will not introduce 100 samples of latency, but only one, as their results will be calculated sequentially, and the result will be passed down to the next module, which will be calculated next -all within the 96kHz time frame.

Ok. Thank you for clarifying this.

Quote:
And the G2 patch compiler is pretty smart in that it first will determine feedback loops and unidirectional strings of modules, and make sure that those are calculated in sequence from first to last module. Besides that, the calculation sequence will follow a "top-down, left-right" scheme pertaining module placement on the editor screen.


Let us have 3 modules in a patch, and 3 samples:

A) Oscillator
B) 1 Channel Mixer
C) Out Module

A outputs x in the first sample.
A outputs y in the second sample.

As I click the Run button on the G2, the first sample is fired, and we have 10.4 micro seconds to do the following:

A outputs x, and this goes into the chain input of B;
The output of B goes back into itself through Channel 1 input, and it also goes to the input of C.

Instantly, A outputs x into memory, then B pickup x from Memory;

Then, [B outputs x into memory, then C pickup x from Memory], or;
[B outputs x into itself through Channel 1, performs the sum (Chain + Channel 1) = (x+x) = 2x, then it outputs 2x into Memory, then C pickup 2x from Memory];

Then, C sends x or 2x to Memory so that it gets ready to be instantly outputted at the tick of sample 2.

**********************************************

Sample 2 is fired:

Instantly, Memory outputs x or 2x into the DA.

Then, A outputs y into Memory, then B pickup y from Memory; B also pickup x or 2x from Memory.
Then, [B outputs y+x into Memory]; or
[B outputs y+2x into Memory]; or
[B outputs y+(y+x) into Memory]; or
[B outputs y+(y+2x) into Memory]; or
[B outputs y+y into Memory]; and C pickup whichever value B have just outputted to Memory.

Then, C sends whichever value it picked up from the results of the operations performed by B, to Memory so that it gets ready to be instantly outputted at the tick of sample 3.

Quote:
So, in basic scenarios, one doesn't have to give all of this a single thought and can just patch away freely.


Thank you for telling me about this, but I am already aware of this. I am not inquiring on the nature of this processes in order to meet practical ends; I just feel attracted to comprehend this matters with mathematical certainty. And I find the rabbit hole to be very fascinating... Smile
Back to top
View user's profile Send private message
varice



Joined: Dec 29, 2004
Posts: 929
Location: Northeastern shore of Toledo Bend
Audio files: 29
G2 patch files: 53

PostPosted: Tue Jun 28, 2016 1:07 pm    Post subject: Reply with quote  Mark this post and the followings unread

The G2 DSP chips are specified to work at a clock frequency up to 150 MHz, but I don’t know what clock frequency the G2 uses.

I tried an internet search on the markings on a component that I think is the crystal/oscillator used as a clock, but I was not able to find any definite info about that part. Maybe someone else could have better luck. The marking on the component:

E 53.6203C
2PC 4016G

The letter E is bold. Maybe it is a manufacturer’s symbol or logo?

_________________
varice
Back to top
View user's profile Send private message
Blue Hell
Site Admin


Joined: Apr 03, 2004
Posts: 22884
Location: The Netherlands, Enschede
Audio files: 239
G2 patch files: 319

PostPosted: Tue Jun 28, 2016 4:52 pm    Post subject: Reply with quote  Mark this post and the followings unread

Tim Kleinert wrote:
Sorry Jan, but I have to correct you here.


Ah yes, of course, don' t know where i got that idea ...

Anyway ... what you also said, the PC ... it depends a bit ... traditionally a DSP can combine some operations that a general purpose CPU can not.

To go into that, basic operations are split into even more basic operations. There are memory fetches, memory stores, CU operations like add or multiply. A DSP can fetch data from a couple of memory locations simultaneously and it can combine some arithmetic operations to run in one clock cycle.

A general purpose CPU can not usually do all that stuff, although the more recent Intel thingies can do some it. This, apart from the 'household stuff' a PC has to do, will make the PC relatively slow compared to a DSP. But yes, it can do more actually than the G2 does, but not as much more as the clock rate comparison suggests. The four core thing ... the G2 has four cores too, or eight when expanded, it also has a separate househould processor to keep the knobs / display / MIDI going.

An issue with multiple cores is that when you spread out a patch over them the cores will need to communicate with each other, something that can be done in the G2 very efficiently, but less so on a PC.

Re. benefits from a faster processor. I think the latency issue is not really an issue, well on a PC it can still be as the audio I/O needs a little buffering there, and it still very much depends on driver quality there how low you can go. Faster processing can result in better audio tho. This whole sample thing is a trade-off between computational speed and audio quality - as in: you could use extra clock cycles to make things sound better. And there are some audible issues there with the G2 when you modulate things in a wild way, things you could improve with spending more processor time.

I think that the demo version of the G2 is pretty good, as in having the same quality as the G2 itself.

_________________
Jan
also .. could someone please turn down the thermostat a bit.
Posted Image, might have been reduced in size. Click Image to view fullscreen.
Back to top
View user's profile Send private message Visit poster's website
marioisaac



Joined: Jan 24, 2016
Posts: 26
Location: Panama

PostPosted: Tue Jun 28, 2016 6:23 pm    Post subject: Reply with quote  Mark this post and the followings unread

Blue Hell wrote:


A general purpose CPU can not usually do all that stuff, although the more recent Intel thingies can do some it. This, apart from the 'household stuff' a PC has to do, will make the PC relatively slow compared to a DSP. But yes, it can do more actually than the G2 does, but not as much more as the clock rate comparison suggests. The four core thing ... the G2 has four cores too, or eight when expanded, it also has a separate househould processor to keep the knobs / display / MIDI going.


Well before asking here this questions I read the G2 Manual, and there it is stated that the extra DSP Chips work in parallel but are only able to replicate the operations contained in one chip for extra voices. They act solely as "voice expanders", so they do not really provide "xtra free CPU power to keep adding modules and connections"

I wonder if the Intel multi-core CPU's work in this same fashion, or if they are able to perform completely different processes at the same time.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic Moderators: Nord Modular Editors
Page 1 of 1 [10 Posts]
View unread posts
View new posts in the last week
Mark the topic unread :: View previous topic :: View next topic
 Forum index » Clavia Nord Modular » Nord Modular G2 Discussion
Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum
e-m mkii

Please support our site. If you click through and buy from
our affiliate partners, we earn a small commission.


Forum with support of Syndicator RSS
Powered by phpBB © 2001, 2005 phpBB Group
Copyright © 2003 through 2009 by electro-music.com - Conditions Of Use