electro-music.com   Dedicated to experimental electro-acoustic
and electronic music
 
    Front Page  |  Radio
 |  Media  |  Forum  |  Wiki  |  Links
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 » Nomad - NM1 Open Source Editor
Module calculation order
Post new topic   Reply to topic Moderators: Nord Modular Editors
Page 1 of 2 [33 Posts]
View unread posts
View new posts in the last week
Mark the topic unread :: View previous topic :: View next topic
Goto page: 1, 2 Next
Author Message
polychoron



Joined: Dec 12, 2006
Posts: 16
Location: Eindhoven, the Netherlands

PostPosted: Wed Jan 24, 2007 2:52 pm    Post subject: Module calculation order
Subject description: Feature request
Reply with quote  Mark this post and the followings unread

Dear developers,

thank you, thank you, thank you!

There is a feature that I would love to see in Nomad.

Clavia's editor makes it very hard to manage the calculation order of the modules, which is necessary to control the relative latency of signals in a patch. We're speaking of latencies in the order of a few audio cycles here, but still these can be important somtimes. For instance when one the desired effect of mixing two signals depends critically on phase differences, like when building a FIR filter. A search on `module calculation order' in this forum will tell you more.

One can only assume that the order in which the modules appear in the patch file is the order in which they are computed in the NM (I have not tested this as I do not know how to edit a patch file properly).

My guess is that the modules themselves do not have any latency, but latency is purely generated by delaying the further processing of a signal to the next audio cycle because the module that is supposed to handle the signal already has had its turn in this cycle (please guru's correct me if i'm wrong).
If that is true, it is possible to determine a calculation order that gives `minimal' latency differences (NO differences where there are no feedback loops). That might be good for most people in in most cases, so a button that fixes the module ordering in the patch this way would be a nice feature too.

The G2 automatically computes an `optimal' module ordering and from the description in the G2 manual (p.139) I can more more less guess what they are up to. I can provide you with algorithms if you like (I'm a mathematician) --- but I cannot write java code, unfortunately.
If the words `directed graph', `topological ordering' and `strongly connected component' ring a bell, then you probably already know what they are doing too.

Apart from avoiding latency it might also be interesting to create latency on purpose. NM's delay module is overkill if one only wants a fixed delay of a few cycles. The same can be done by routing the signal through cheap modules and ordering them `backwards'.

Thanks again,
Rudi
Back to top
View user's profile Send private message
blue hell
Site Admin


Joined: Apr 03, 2004
Posts: 24079
Location: The Netherlands, Enschede
Audio files: 278
G2 patch files: 320

PostPosted: Wed Jan 24, 2007 3:46 pm    Post subject: Reply with quote  Mark this post and the followings unread

I think your assumptions to be correct basically, except maybe for the no latency bit re. modules, I'd expect filters f.i. would have latency.

I think this is a great idea. To simplify things the same trick that is used by the G2 could be used, i.e. reordering only for red (audio rate) signals.

Otoh .. reordering will benefit the design of asynchroneous logic circuits as well. No more late triggering or glitches, if the modules are properly ordered.

_________________
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
polychoron



Joined: Dec 12, 2006
Posts: 16
Location: Eindhoven, the Netherlands

PostPosted: Thu Jan 25, 2007 2:28 am    Post subject: Reply with quote  Mark this post and the followings unread

It should be possible to make an ordering that always does most justice to the audio signals but also tries to optimize the ordering for control&logic signals.

After `lumping together' the sets of modules that contain audio feedback the set of lumps can always be ordered so that least the signals between the lumps travel downstream.
In general, there will more than one ordering of the lumps that is 'safe' for audio signals in this way, and there is still a choice of ordering the modules within each lump. So there is room to choose a best ordering for control signals here.

What is `best' is a matter of choice and would also depend on how the updates of control and audio signals are mixed. I know the rates are different, but what happens exactly? Is one in four audio cycles one that updates all control signals?

Anyway, I would already be very happy if I had manual control over the ordering. The simplest thing I can think of is a button that uploads the patch with the ordering of the modules as it appears on screen, with columns from left to right and within each column from the top to the bottom.

Cheers,
Rudi
Back to top
View user's profile Send private message
chresan



Joined: Jul 11, 2006
Posts: 150
Location: Karlsruhe, Germany

PostPosted: Thu Jan 25, 2007 4:38 am    Post subject: Reply with quote  Mark this post and the followings unread

Hi Rudi,

I will add this feature to nomad. But you have to provide some documentation about the behaviour / algorithm if you want me to do it. I am aware of the mathematical nomenclature and graph theory so you don't have to find another way to explain things.

About the module order. Modules are stored in the ModuleDump sections of a patch file using four integers: (index, id, x, y). I have seen some patch files where the order of the tupels and the order implied by the index-variable are different. It would help to know which order is important to the calculation order.

I think the best way to add this feature is to provide a command 'optimize latency' rather than optimizing a patch automatically. Otherwise it would be necessary to delete modules/cables and recreate them if a new module is added to keep the correct order.

Optimizing the positions of modules is no problem. I think I can add both an option to optimize the current layout and an option to do this automatically if modules/cables have changed.

Finally, you should be patient until this feature is implemented. I already have a huge list of things to do which are more important at the moment. But I think these features can be implemented after the next release.

Sincerely,
Christian

_________________
----------------------
http://nmedit.sf.net
Back to top
View user's profile Send private message Visit poster's website
blue hell
Site Admin


Joined: Apr 03, 2004
Posts: 24079
Location: The Netherlands, Enschede
Audio files: 278
G2 patch files: 320

PostPosted: Thu Jan 25, 2007 4:51 am    Post subject: Reply with quote  Mark this post and the followings unread

polychoron wrote:
Is one in four audio cycles one that updates all control signals?

As far as I know the control load is split into four parts and for every audio cycle a quarter of the control rate signals is processed. It can't be known what part will be updated in which audio cycle.
Quote:

Anyway, I would already be very happy if I had manual control over the ordering. The simplest thing I can think of is a button that uploads the patch with the ordering of the modules as it appears on screen, with columns from left to right and within each column from the top to the bottom.

I agree, and it should be optional indeed IMO as well as there may be existing patches that were carefully crafted for some execution order (I know of people who experimented with that). And this is possible of course but very close to undoable Very Happy

And to, hopefully, answer Christian :

The current execution order is the insertion order of modules into the patch, but holes caused by deletions will be re-used - this maps onto the module index number as used in the patch file.

_________________
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
polychoron



Joined: Dec 12, 2006
Posts: 16
Location: Eindhoven, the Netherlands

PostPosted: Thu Jan 25, 2007 5:50 am    Post subject: Reply with quote  Mark this post and the followings unread

Hi Christian,

chresan wrote:

I will add this feature to nomad. But you have to provide some documentation about the behaviour / algorithm if you want me to do it. I am aware of the mathematical nomenclature and graph theory so you don't have to find another way to explain things.


That's great! I will come back with a careful writeup of the algorithm within the next few days.

chresan wrote:

About the module order. Modules are stored in the ModuleDump sections of a patch file using four integers: (index, id, x, y). I have seen some patch files where the order of the tupels and the order implied by the index-variable are different. It would help to know which order is important to the calculation order.


Frankly, I do not know which is the relevant ordering. I will experiment to find out.

chresan wrote:

I think the best way to add this feature is to provide a command 'optimize latency' rather than optimizing a patch automatically. Otherwise it would be necessary to delete modules/cables and recreate them if a new module is added to keep the correct order.


I agree that a command is better than an automatic function running in the background, but because I think that the behaviour of any interface should be as predictable as possible. The editor should not be doing things one did not ask for.

I do not really know how the editor communicates patch changes to the NM. I sort of assumed that the editor merely communicates patch modifications and these are carried out in the NM and in the editor in parallel. If that is true, then there is a risk that the module order in the NM diverges from the module order in the editor. Except if module id's are communicated and these determine the ordering --- that would be my best guess right now.

chresan wrote:

Optimizing the positions of modules is no problem. I think I can add both an option to optimize the current layout and an option to do this automatically if modules/cables have changed.


You seem to be thinking of adapting the module locations on screen to the patch order on file.
I was thinking of the converse, adapting the order in the patch to follow the order given by the locations of the modules on the screen.

chresan wrote:

Finally, you should be patient until this feature is implemented. I already have a huge list of things to do which are more important at the moment.
But I think these features can be implemented after the next release.

Your work is much appreciated.

Kind regards,
Rudi
Back to top
View user's profile Send private message
polychoron



Joined: Dec 12, 2006
Posts: 16
Location: Eindhoven, the Netherlands

PostPosted: Thu Jan 25, 2007 6:13 am    Post subject: Reply with quote  Mark this post and the followings unread

Blue Hell wrote:
polychoron wrote:
Is one in four audio cycles one that updates all control signals?

As far as I know the control load is split into four parts and for every audio cycle a quarter of the control rate signals is processed. It can't be known what part will be updated in which audio cycle.

That makes sense if you want to balance the dsp load over the 4 consecutive cycles, but I find it hard to imagine what is going on here. Are pure control modules out of the loop 3/4 of the time perhaps? What about envelopes?


Blue Hell wrote:

The current execution order is the insertion order of modules into the patch, but holes caused by deletions will be re-used - this maps onto the module index number as used in the patch file.

That makes life easier --- thanks.
Back to top
View user's profile Send private message
blue hell
Site Admin


Joined: Apr 03, 2004
Posts: 24079
Location: The Netherlands, Enschede
Audio files: 278
G2 patch files: 320

PostPosted: Thu Jan 25, 2007 7:32 am    Post subject: Reply with quote  Mark this post and the followings unread

polychoron wrote:
Are pure control modules out of the loop 3/4 of the time perhaps? What about envelopes?


Some specultion here Very Happy ...

I think Clavia stores computed values into memory locations associated with outputs, as modules having many outputs tend to use more DSP memory. Inputs then have to be fetched from those memory locations. You can check on the various memory resources used through the menu, but I don't have the editor installed here (at work), so can't tell which one now. There is more than is visible in the tool bar.

For a blue input sampling a red output that would mean that one arbitrary one value out of four values would be used, for a blue output it would mean that a red input would see the same value four times.

_________________
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
polychoron



Joined: Dec 12, 2006
Posts: 16
Location: Eindhoven, the Netherlands

PostPosted: Thu Jan 25, 2007 8:45 am    Post subject: Reply with quote  Mark this post and the followings unread

Hi Jan,

Thanks for your comments, I think I'm getting the picture now. Signals take space, modules take time. Signals have to be available, and there's not much to be done about that. But the time taken by the collection of modules that have control outputs only can be split over 4 audio cycles. The question is, how have they done this splitting? If they split the execution of an individual module over several cycles they would have to remember intermediate results from one cycle to the next. It is unlikely that they would split up many control modules this way.

So either they do each control module completely within an audio cycle (but only 1 out of 4), but then the DSP time load would vary over 4 consecutive audio cycles. Or, they have a control cycle parallel to 4 audio cycles in which some control modules cross the boundary between two audio cycles. My bets are on the first one. I have noticed that the NM editor can be wrong about the feasibility of a patch especially if there are many control modules.

Blue Hell wrote:

Some specultion here Very Happy ...

Speculation rules. Cool
Especially since I'm at work and cannot test any of this...

Cheers,
Rudi
Back to top
View user's profile Send private message
blue hell
Site Admin


Joined: Apr 03, 2004
Posts: 24079
Location: The Netherlands, Enschede
Audio files: 278
G2 patch files: 320

PostPosted: Thu Jan 25, 2007 8:59 am    Post subject: Reply with quote  Mark this post and the followings unread

polychoron wrote:
My bets are on the first one.


Mine as well, I remember people describing it that way.
Quote:

Speculation rules. Cool
Especially since I'm at work and cannot test any of this...


Right, me to, but let's assume we have a coffee break Very Happy

_________________
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
polychoron



Joined: Dec 12, 2006
Posts: 16
Location: Eindhoven, the Netherlands

PostPosted: Fri Jan 26, 2007 1:53 pm    Post subject: Reply with quote  Mark this post and the followings unread

To test my ideas on how latency is affected by module order and whatnot I did some experiments. I found some things that are very strange indeed. Take a look at the patch below.
As it is, it does what is to be expected. A saw is substracted from itself and the result is silence. But delete module InvLevShift1, and you HEAR that the self substraction is no longer perfect as a result of latency differences (there are spikes on my oscilloscope at the discontinuities of the saw).

The strange thing is, this module InvLevShift1 was not even connected to any other module Shocked .The order of the other modules is not affected in any sense by the deletion, if you look at the patch file.

My hypothesis that latency is detemined by module order alone is killed by this example, and if I do not have a firm grip on what causes latency, I cannot come up with an automated repair strategy either. Embarassed

So I need to do more testing. I would still appreciate it if Nomad were to include the possibility to control the module order, to simplify all that testing (i have to start over patching for practically each change now).

---Rudi


Very odd.pch
 Description:
Delete InvLevShift1 to get sound!

Download
 Filename:  Very odd.pch
 Filesize:  849 Bytes
 Downloaded:  419 Time(s)


Last edited by polychoron on Sun Feb 04, 2007 1:39 am; edited 1 time in total
Back to top
View user's profile Send private message
blue hell
Site Admin


Joined: Apr 03, 2004
Posts: 24079
Location: The Netherlands, Enschede
Audio files: 278
G2 patch files: 320

PostPosted: Fri Jan 26, 2007 4:32 pm    Post subject: Reply with quote  Mark this post and the followings unread

Hmm, that's not quite what I had in mind.

It will take some energy to sort that out Sad

edit : but at least it's reproducable here.

_________________
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
polychoron



Joined: Dec 12, 2006
Posts: 16
Location: Eindhoven, the Netherlands

PostPosted: Sat Jan 27, 2007 8:01 am    Post subject: Reply with quote  Mark this post and the followings unread

Well, I'm less pessimistic now.

Playing around with the `very odd' patch I noticed that if you replace InvLevShft1 with another module, the result depends on whether the new module has audio in-or outputs. If it has, the sound stops. If its control/logic only, the sound continues. And I played around some more with other modules in similar configurations. What I've seen is consistent with this:

1) control modules are in an independent, slower cycle. The ordering in either cycle is the index order of the modules.

2) If audio input from module M goes to module N, then there are two reasons why N would receive the signal with latency 1, i.e. data form the previous cycle:
a) N is executed before M; or
b) N is executed immediately after M, and the signal is on a specific output of M and a specific input of N.

For instance, the 4-1 switch only has this behaviour on the first input, gaincontrol has the problem only on the audio input and not on the multiplier (`control') input, multimode filter D only has it on the bandpass output, etc.

I have not gotten around to checking up the control cycle very thoroughly.
But if this is really all there is to it, there is a workaround for it.

--Rudi
Back to top
View user's profile Send private message
blue hell
Site Admin


Joined: Apr 03, 2004
Posts: 24079
Location: The Netherlands, Enschede
Audio files: 278
G2 patch files: 320

PostPosted: Sat Jan 27, 2007 9:02 am    Post subject: Reply with quote  Mark this post and the followings unread

Rudi,

are you on a PC - if so I might be able to construct a utility for you that rearanges the module indices. I found some old Delphi code that looks like it could do it with a few modifications. Or if you want the code to hack it yourself that;s OK as well.

Alternatively, for the Classic -> G2 patch conversion Python code is available that is able to read and interpret Classic patches - that one probably would be able to do it as well with some modificatons. Thay would be platform independent, but if I'd have to progam in Python, then, well, erm, I'm a virgin really ....

I think both would be more suitable for some quick hacking than the Nomad code, not that it is no good, but the it would be more code to sort out.

_________________
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
chresan



Joined: Jul 11, 2006
Posts: 150
Location: Karlsruhe, Germany

PostPosted: Sat Jan 27, 2007 9:25 am    Post subject: Reply with quote  Mark this post and the followings unread

Blue Hell wrote:

...
I think both would be more suitable for some quick hacking than the Nomad code, not that it is no good, but the it would be more code to sort out.


The code related to modifying patch files is independent from nomad. If it helps I can repackage it. Then it could be used too.

_________________
----------------------
http://nmedit.sf.net
Back to top
View user's profile Send private message Visit poster's website
blue hell
Site Admin


Joined: Apr 03, 2004
Posts: 24079
Location: The Netherlands, Enschede
Audio files: 278
G2 patch files: 320

PostPosted: Sat Jan 27, 2007 3:08 pm    Post subject: Reply with quote  Mark this post and the followings unread

Ok, I made a little something like in screen dump below (don'[t mind the title bar, it's an old one). Any suggestions for what other operations besides swap indices would be needed ?


exui.png
 Description:
-
 Filesize:  14.41 KB
 Viewed:  18729 Time(s)

exui.png



_________________
Jan
also .. could someone please turn down the thermostat a bit.
Posted Image, might have been reduced in size. Click Image to view fullscreen.

Last edited by blue hell on Thu Aug 23, 2007 1:58 pm; edited 1 time in total
Back to top
View user's profile Send private message Visit poster's website
polychoron



Joined: Dec 12, 2006
Posts: 16
Location: Eindhoven, the Netherlands

PostPosted: Sat Jan 27, 2007 3:28 pm    Post subject: Reply with quote  Mark this post and the followings unread

Hi Jan,

that looks very nice! I don't have any other wishes.

Except perhaps a `reload patch' button for quickly checking if the order is what i think it is if i've made minor changes in the patch using the editor. If the normal `load' remembers paths that's OK too.

So far, everything i've seen fits the description. I'm now at systematically checking which outputs have the latency problem. Then the inputs, and i'll try and measure the internal latency of modules..

How do I get your program, Jan?

---Rudi
Back to top
View user's profile Send private message
blue hell
Site Admin


Joined: Apr 03, 2004
Posts: 24079
Location: The Netherlands, Enschede
Audio files: 278
G2 patch files: 320

PostPosted: Sat Jan 27, 2007 3:56 pm    Post subject: Reply with quote  Mark this post and the followings unread

polychoron wrote:

How do I get your program, Jan?


It seems to work, but I have to run a few more checks, like seeing if the saved patch is actually loadable for the NM editor. When done I'll post it here for you to check out, hopefully in time Very Happy

The idea is to set a patch name by the browse button and then load and save will use that patch name. So you save in the editor, load in my program or the other way around and things are synced again.

Good to see your investigations pay of sofar.

_________________
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
blue hell
Site Admin


Joined: Apr 03, 2004
Posts: 24079
Location: The Netherlands, Enschede
Audio files: 278
G2 patch files: 320

PostPosted: Sat Jan 27, 2007 4:13 pm    Post subject: Reply with quote  Mark this post and the followings unread

Ok, it seems to work, so here it is. Please note that this is windows software.

Just unzip the zip to a directory that seems suitable for you to use. The zip contains an exe file, the license agreement (GPL) and a folder with some resource files used by the exe. When running the program it will write an ini file to the same folder as where the exe is located.

Just run the exe, then browse for the patch you want to mangle, then click Load to load the patch and when done mangling click ssave to save it - it will overwrite the old patch then (so maybe make copies of valuable patches before using this). The patches have to be in 3.0x format.

When it's found to be OK I'll post it on my web site along with the source code.

When you want additional functionality or bugfixes feel frre to ask.

(*)


patch_sorter.zip
 Description:
An NM Classic patch mangler

Download
 Filename:  patch_sorter.zip
 Filesize:  391.17 KB
 Downloaded:  363 Time(s)


_________________
Jan
also .. could someone please turn down the thermostat a bit.
Posted Image, might have been reduced in size. Click Image to view fullscreen.

Last edited by blue hell on Thu Aug 23, 2007 1:57 pm; edited 1 time in total
Back to top
View user's profile Send private message Visit poster's website
polychoron



Joined: Dec 12, 2006
Posts: 16
Location: Eindhoven, the Netherlands

PostPosted: Sun Jan 28, 2007 12:44 am    Post subject: Reply with quote  Mark this post and the followings unread

Hi Jan, thanks for the program, it works fine here.
I cannot do as much on this thing in the next few days.
I had a lot of ehrm .. coffee breaks lately Rolling Eyes and now there are some deadlines creeping up on me. But I'll be back.
--Rudi
Back to top
View user's profile Send private message
chresan



Joined: Jul 11, 2006
Posts: 150
Location: Karlsruhe, Germany

PostPosted: Sun Jan 28, 2007 8:17 am    Post subject: Reply with quote  Mark this post and the followings unread

Rudi, I tried the 'very odd' patch the first time. Afterwards I tried a few theories/patches and I think I found a interesting scenario:
First create a sequence of modules A, then a sequence of modules B where the number of modules in each sequence is even. For simplification use only InvLevShift modules (but it works with different audio modules too).
For example use 4 modules, then you get A:1, 2, 3, 4 and B:5,6,7,8.
Well then you can create the oscillator, mixer and output module like in your example. Make sure that only modules in a sequence are connected with each other so A and B do not depend on each other. When you connect the modules in a sequence make sure that the index order is retained. For example A:1-2-4 is ok but not A:1-4-2 because 4>2.
Then make sure that in each sequence always the same numbers of modules are connected, for example: A:1-2-3 and B:5-6-7 or A:1-2 and B:7-8.
If you do that interesting patterns will emerge. Depending on the combinations you get either noise or silence. After I tried some of them I think following is accurate: Two modules with index 2x-1 and 2x are calculated in the same cycle (2x-1,2x). If one of these modules is not connected for example [2x-1], then [2x] still needs one cycle (_,2x).

Using this notation you can write down the cycles of A/B and compare them with each other. For example in A/B the connections are A:1-2-3 and B:5-6-7-8, then you get:
A: (1,2)(3,_ )
B: (5,6)(7,8 )
In this case you can hear noise because they do not overlap correctly. In a simmilar case A:1-2-4, B:5-6-8 you get:
A: (1,2)(_,4)
B: (5,6)(7,8 )
Now they overlap and no noise can be heard.

Now to my notation. I know that the resolution of 1/2 cycles is strange. But you will figure out that it makes sense, because there are some cases where you have to combine two cycles (a,_) and (_,d) in one (a,d). Perhaps there is some optimization going on.

Back to your example patch you can explain the behaviour using this notation. You have created 1oscillator {1} and 3invlevelshift modules {2,3,4} with {2} not connected. which means the cycles are
X: (1,_ )
A: (3,4)
Here you can see that 3/4 are processed both in one cycle, but if you delete {2}, then you get:
X: (1,3)
A: (4,_ )
now 3/4 are processed in different cycles with 1/2 cycle difference, thus noise can be heard.

Ok, I hope my explanation is not too confusing and sorry if my english is not always the best Embarassed

Christian


combinat.pch
 Description:
testing combinations

Download
 Filename:  combinat.pch
 Filesize:  994 Bytes
 Downloaded:  348 Time(s)


_________________
----------------------
http://nmedit.sf.net
Back to top
View user's profile Send private message Visit poster's website
polychoron



Joined: Dec 12, 2006
Posts: 16
Location: Eindhoven, the Netherlands

PostPosted: Mon Jan 29, 2007 3:29 am    Post subject: Reply with quote  Mark this post and the followings unread

Hi Christian,

I dont think I fully understand. Do you say that in the ordering of the modules, parity makes a difference? Could you create sequences of modules A,B C so that

A, dummy, B, dummy, dummy, C

behaves different from

A, dummy, dummy, B, dummy, C

?

Here a dummy is an audio module not connected to anything. My theory would say that there is no difference between padding with one and padding with many dummies, so that these two would behave the same.

--Rudi
Back to top
View user's profile Send private message
chresan



Joined: Jul 11, 2006
Posts: 150
Location: Karlsruhe, Germany

PostPosted: Mon Jan 29, 2007 11:18 am    Post subject: Reply with quote  Mark this post and the followings unread

polychoron wrote:
Hi Christian,

I dont think I fully understand. Do you say that in the ordering of the modules, parity makes a difference? Could you create sequences of modules A,B C so that

A, dummy, B, dummy, dummy, C

behaves different from

A, dummy, dummy, B, dummy, C

?

Here a dummy is an audio module not connected to anything. My theory would say that there is no difference between padding with one and padding with many dummies, so that these two would behave the same.

--Rudi

No, not exactly. According to my notation the cycles would look like:
A: (A,_)(B,_)(_,C) and
B: (A,_)(_,B)(_,C)
well (B,_) and (_,B) do not match each other, but important is that (_,C) is equal in both sequences which means there is no noise (and there really is no noise, I tried it).

I have tried another configuration with the result that the explanation in my previous posting is not correct. However, it also indicates that it is important whether two modules are neighbours or not (neighbour means that for their module indices a,b the equation b=a+1 is true )
I give you an example (I use 'x' instead of the term 'dummy')
I have following configuration that I want to compare to:
A,x, x,x, E,x

Now I start comparing against:
Code:

A,x, x,x, E,x  (silent)
x,B, x,x, E,x  (silent)
x,x, C,x, E,x  (silent)
x,x, x,D, E,x  (noise)
A,B, x,x, x,x  (noise)
A,x, C,x, x,x  (silent)
A,x, x,D, x,x  (silent)
A,x, x,x, x,F  (silent)

Now I make it more complex by using three modules
Code:

A,B, x,x, E,x  (noise)
A,x, B,x, E,x  (silent)
A,x, x,C, E,x  (noise)
A,x, x,C, x,F  (silence)
x,A, x,C, x,F  (silence)
...

What is interesting about that is you can always hear noise if two modules are neighbours, otherwise not.

I hope this explanation is better to understand Embarassed

Christian

_________________
----------------------
http://nmedit.sf.net
Back to top
View user's profile Send private message Visit poster's website
polychoron



Joined: Dec 12, 2006
Posts: 16
Location: Eindhoven, the Netherlands

PostPosted: Mon Jan 29, 2007 11:45 am    Post subject: Reply with quote  Mark this post and the followings unread

chresan wrote:

...it also indicates that it is important whether two modules are neighbours or not (neighbour means that for their module indices a,b the equation b=a+1 is true )


Yes, that is exactly what I find too. There is something subtle going on: to get the extra delay the signal must go from a module to its direct successor AND the output must be a specific one, AND the input must be a special one. For example, the HP and LP outs of filter D are never affected, but BP is.

To be precise, I think that
--it is specific to the module which ins and outs are affected and
-- that there is an extra delay if and only if the signal goes from M to N, N is direct successor of M, the in of N is affected and the out of M is affected.

I've been working to make a list of affected in-and outputs for each audio module, but right now I do not have time to continue. Tomorrow...

---Rudi
Back to top
View user's profile Send private message
polychoron



Joined: Dec 12, 2006
Posts: 16
Location: Eindhoven, the Netherlands

PostPosted: Wed Jan 31, 2007 2:40 pm    Post subject: Reply with quote  Mark this post and the followings unread

Hi All,

I'm measuring latency against the delay module, but I'm slow. I include the measurements I made so far below. Empty fields are just not done yet. The numbering of in-and outputs is the patch file numbering (thanks for your documents on the patch file format Jan).

There is one very strange result. I thought the internal sampling rate was 96 kHz. All latencies I measure are are (multiples of) 1/96000Hz, which fits. But the 4-1-switch has an internal latency of half of that --- so every signal gets a delay of half a sample. I cannot explain this. If you have the time, take a look at it. It's the only module (so far) with an internal latency, too.

Anyway, I'm collecting this data, but at the same time I would be very happy if we could avoid relying on it. This kind of measuring is prone to errors. And even if I do check each module against some module, I still don't know if each pair of successive modules behaves as predicted.

I think the more reliable find is that this extra latency between successive modules goes away when you place a module inbetween them. Without the latency `bug' (I hesitate to call it a `feature') the problem of ordering modules latency-free would have been easy. And with the extra demand of avoiding successive pairs that are connected it is probably a nasty combinatorial optimization problem in general, but we're not speaking of hundreds of modules here; there must be a practical solution. So I will first make a reordering procedure of this type.
That will not necessarily produce a latency-free ordering if one exists, so a procedure that really works with detailed knowledge of where exactly extra latency might arise is still wanted then.

--Rudi


Latency.txt
 Description:
Latency bug measurements --- unfinished

Download
 Filename:  Latency.txt
 Filesize:  1.01 KB
 Downloaded:  351 Time(s)


4-1Switch.pch
 Description:
Internal latency of 4-1Switch is .5

Download
 Filename:  4-1Switch.pch
 Filesize:  1.11 KB
 Downloaded:  343 Time(s)

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 2 [33 Posts]
View unread posts
View new posts in the last week
Goto page: 1, 2 Next
Mark the topic unread :: View previous topic :: View next topic
 Forum index » Clavia Nord Modular » Nomad - NM1 Open Source Editor
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


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