Author |
Message |
polychoron
Joined: Dec 12, 2006 Posts: 16 Location: Eindhoven, the Netherlands
|
Posted: Wed Jan 24, 2007 2:52 pm Post subject:
Module calculation order Subject description: Feature request |
|
|
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
|
|
|
blue hell
Site Admin
Joined: Apr 03, 2004 Posts: 24075 Location: The Netherlands, Enschede
Audio files: 277
G2 patch files: 320
|
Posted: Wed Jan 24, 2007 3:46 pm Post subject:
|
|
|
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.
|
|
Back to top
|
|
|
polychoron
Joined: Dec 12, 2006 Posts: 16 Location: Eindhoven, the Netherlands
|
Posted: Thu Jan 25, 2007 2:28 am Post subject:
|
|
|
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
|
|
|
chresan
Joined: Jul 11, 2006 Posts: 150 Location: Karlsruhe, Germany
|
Posted: Thu Jan 25, 2007 4:38 am Post subject:
|
|
|
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
|
|
|
blue hell
Site Admin
Joined: Apr 03, 2004 Posts: 24075 Location: The Netherlands, Enschede
Audio files: 277
G2 patch files: 320
|
Posted: Thu Jan 25, 2007 4:51 am Post subject:
|
|
|
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
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.
|
|
Back to top
|
|
|
polychoron
Joined: Dec 12, 2006 Posts: 16 Location: Eindhoven, the Netherlands
|
Posted: Thu Jan 25, 2007 5:50 am Post subject:
|
|
|
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
|
|
|
polychoron
Joined: Dec 12, 2006 Posts: 16 Location: Eindhoven, the Netherlands
|
Posted: Thu Jan 25, 2007 6:13 am Post subject:
|
|
|
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
|
|
|
blue hell
Site Admin
Joined: Apr 03, 2004 Posts: 24075 Location: The Netherlands, Enschede
Audio files: 277
G2 patch files: 320
|
Posted: Thu Jan 25, 2007 7:32 am Post subject:
|
|
|
polychoron wrote: | Are pure control modules out of the loop 3/4 of the time perhaps? What about envelopes? |
Some specultion here ...
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.
|
|
Back to top
|
|
|
polychoron
Joined: Dec 12, 2006 Posts: 16 Location: Eindhoven, the Netherlands
|
Posted: Thu Jan 25, 2007 8:45 am Post subject:
|
|
|
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 ...
|
Speculation rules.
Especially since I'm at work and cannot test any of this...
Cheers,
Rudi |
|
Back to top
|
|
|
blue hell
Site Admin
Joined: Apr 03, 2004 Posts: 24075 Location: The Netherlands, Enschede
Audio files: 277
G2 patch files: 320
|
Posted: Thu Jan 25, 2007 8:59 am Post subject:
|
|
|
polychoron wrote: | My bets are on the first one. |
Mine as well, I remember people describing it that way.
Quote: |
Speculation rules.
Especially since I'm at work and cannot test any of this...
|
Right, me to, but let's assume we have a coffee break _________________ Jan
also .. could someone please turn down the thermostat a bit.
|
|
Back to top
|
|
|
polychoron
Joined: Dec 12, 2006 Posts: 16 Location: Eindhoven, the Netherlands
|
|
Back to top
|
|
|
blue hell
Site Admin
Joined: Apr 03, 2004 Posts: 24075 Location: The Netherlands, Enschede
Audio files: 277
G2 patch files: 320
|
Posted: Fri Jan 26, 2007 4:32 pm Post subject:
|
|
|
Hmm, that's not quite what I had in mind.
It will take some energy to sort that out
edit : but at least it's reproducable here. _________________ Jan
also .. could someone please turn down the thermostat a bit.
|
|
Back to top
|
|
|
polychoron
Joined: Dec 12, 2006 Posts: 16 Location: Eindhoven, the Netherlands
|
Posted: Sat Jan 27, 2007 8:01 am Post subject:
|
|
|
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
|
|
|
blue hell
Site Admin
Joined: Apr 03, 2004 Posts: 24075 Location: The Netherlands, Enschede
Audio files: 277
G2 patch files: 320
|
Posted: Sat Jan 27, 2007 9:02 am Post subject:
|
|
|
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.
|
|
Back to top
|
|
|
chresan
Joined: Jul 11, 2006 Posts: 150 Location: Karlsruhe, Germany
|
Posted: Sat Jan 27, 2007 9:25 am Post subject:
|
|
|
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
|
|
|
blue hell
Site Admin
Joined: Apr 03, 2004 Posts: 24075 Location: The Netherlands, Enschede
Audio files: 277
G2 patch files: 320
|
|
Back to top
|
|
|
polychoron
Joined: Dec 12, 2006 Posts: 16 Location: Eindhoven, the Netherlands
|
Posted: Sat Jan 27, 2007 3:28 pm Post subject:
|
|
|
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
|
|
|
blue hell
Site Admin
Joined: Apr 03, 2004 Posts: 24075 Location: The Netherlands, Enschede
Audio files: 277
G2 patch files: 320
|
Posted: Sat Jan 27, 2007 3:56 pm Post subject:
|
|
|
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
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.
|
|
Back to top
|
|
|
blue hell
Site Admin
Joined: Apr 03, 2004 Posts: 24075 Location: The Netherlands, Enschede
Audio files: 277
G2 patch files: 320
|
|
Back to top
|
|
|
polychoron
Joined: Dec 12, 2006 Posts: 16 Location: Eindhoven, the Netherlands
|
Posted: Sun Jan 28, 2007 12:44 am Post subject:
|
|
|
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 and now there are some deadlines creeping up on me. But I'll be back.
--Rudi |
|
Back to top
|
|
|
chresan
Joined: Jul 11, 2006 Posts: 150 Location: Karlsruhe, Germany
|
Posted: Sun Jan 28, 2007 8:17 am Post subject:
|
|
|
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
Christian
Description: |
|
Download |
Filename: |
combinat.pch |
Filesize: |
994 Bytes |
Downloaded: |
348 Time(s) |
_________________ ----------------------
http://nmedit.sf.net |
|
Back to top
|
|
|
polychoron
Joined: Dec 12, 2006 Posts: 16 Location: Eindhoven, the Netherlands
|
Posted: Mon Jan 29, 2007 3:29 am Post subject:
|
|
|
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
|
|
|
chresan
Joined: Jul 11, 2006 Posts: 150 Location: Karlsruhe, Germany
|
Posted: Mon Jan 29, 2007 11:18 am Post subject:
|
|
|
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
Christian _________________ ----------------------
http://nmedit.sf.net |
|
Back to top
|
|
|
polychoron
Joined: Dec 12, 2006 Posts: 16 Location: Eindhoven, the Netherlands
|
Posted: Mon Jan 29, 2007 11:45 am Post subject:
|
|
|
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
|
|
|
polychoron
Joined: Dec 12, 2006 Posts: 16 Location: Eindhoven, the Netherlands
|
Posted: Wed Jan 31, 2007 2:40 pm Post subject:
|
|
|
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
Description: |
Latency bug measurements --- unfinished |
|
Download |
Filename: |
Latency.txt |
Filesize: |
1.01 KB |
Downloaded: |
351 Time(s) |
Description: |
Internal latency of 4-1Switch is .5 |
|
Download |
Filename: |
4-1Switch.pch |
Filesize: |
1.11 KB |
Downloaded: |
343 Time(s) |
|
|
Back to top
|
|
|
|