latency of send~ and receive~ objects

i would be interested to continue - how´s your latency compensation system doing?

well, i allready wrote in the other thread. But more detailed again:

A week ago or so i stopped. I created the hardwired graph using the c# code (Just using mc.+~ and mc.delay~)

it was outputing signal. (I saw it on the signal meters. I also checked the connections and it correct.

Yet i didn't hear anything because i was working from remote desktop with no audio. So i could not hear if there is some phasing caused by latency of the mc.+~ objects. But it should be quite simple to add the required number of samples to the delay. I wanted to test this but i started working on a remix project. Yet i wanna think of some test-environ to make it really accurate.

Yet i'm not sure how to continue with the project. Basically it is finished as a dynamic signal plugin chain but i thought of adding sampler and synthesizer features to the nodes. But this is another big task, maybe i will continue some day. I think the strategy is good. I could create any graph dynamically so the virtual synth graph would be very fast as everthing is connected hard wired.

Also i might release the binaries for the current version on maxforlive.com when i finally tested and fixed the last few samples on the delay parameter. Currently all files are are available through github. (See link in my profile page)

Future Stuff:

So v2 of the system may extend the dynamic signal graph with vst plugins to become a modular synthesizer. i think it would be VERY interesting to place lfos and so on and to modulate single plugin parameters. yet the effects i did with different plugins without modulating parameters sounded quite freaky... hehe

But it will be a bit more complex. because i have audio signals and control signals then.

and since every node has several control message AND a audio stream this somehow breaks the logic of the signal chain where every node only has one input and output. although it extends the use case. this is why i'm not sure how to reflect this. though i didn't really think about it.

So basically it could also be understood as some higher level gui-builder for max patchers. Finally i would end up in rebuilding the max gui but that is not the goal. I need to find some simplified concept. Because it should be still the fun of a modular synthesizer and not the bug-searching software development stuff you do in max. This can be done by having a preselected number of basic objects like lfo, envelope etc.

Yet it would be very cool to build your custom modular modules using native max and then include them to that thing that still lacks a name.....

Basically my goal was just to play a bit with a signal graph, latency compensation and max using c#.... Let's see how it will develop.

Any ideas welcome.

btw... if someone wants to listen to some synthpop: here is the remix i did in the mean time.

"But it should be quite simple to add the required number of samples to the delay."

the thing is, i dont find it simple. "normal" PDC is easy, thats a no brainer. but the parallel stuff makes it quite complicated.

what is simple is to look at a custom created graph, knowing that two of the 7 plug-ins have 1024 ms delay, and then insert compensator modules respectively to the other nodes, manually via the GUI.

but to program an auto compensation feature for that thing is different. sure, i had in in my head after 2 minutes, but i dont find an easy way how to implement it, because every node must be checked against all other nodes for beeing connected to the same next node, too.
then sometimes you have to sum up values, sometimes you only have one plug-in with latency, and building a messaging system for this creates a mess.

so mine still without after all the years.

and to be honest i am also not too fond of having 20 active delay objects all the time, just in case i eventually need one or two of them.

about these modules.

well be careful not to recreate max in max. :) different number of outlets (or even variable number of outlets?) makes the system almost unmanagable.

but of course what you could do is always use a maximum number anywhere. for example 4 audio in and 4 audio out everywhere, even when not needed. you could send them again in the fashion of non-MSP forward/receive (like i do it with connection between bpatchers) and press the 4 signals and up to 100 messages/number into a single connection.

a module could output a master phase plus already-divided by 2,4,8 phases and the current speed in BPM as number all throught one cable that way. if it looks cool when you work with it? not sure.

however, if you want to create something which should serve as generic solution, make it as simple as possible in the beginning. t here are a lot of generators, filters, effects, where 1 in 1 out is sufficient.

what is cool about using non signal connection for signals is that you can make themn "incompatible" with each other.

i for example have 3 different sorts of 10-channel connections: generic ones, 10-channel vbap surround sound field, and partial dynamics signals. they have different names and if you connect wrong objects to each other, the signal will not be unpacked inside the receiving object.

that can become very important if you use audio, FFT, CV, and 32 bit parameter signals in your modules.

> must be checked against all other nodes for beeing connected to the same next node, too.

actually it is much simpler. The place where you need to do the delay compensation is the input of a node. here you have to mix several signals, each signal has a delay. so you must calc the max delay and subtract the delay of the individual signal. thats the delay for the compensation. then you forward the signal with the maximum delay, that will be the delay for that signal for the next node.

To make it more applicable it would be nice to have some list of meta info values for an audio stream. So you could comminicate the delay together with the stream requiring only one connection. Then it is easier to avoid some confusion in the patcher. however, since something like this does not exist in max you have to deal with it somehow differently. but doing so would allow max an automatic delay compensation without the user recognizes anything like delaycompensation actually exists.

i allready have this delay compensation running and this works. when i said, it's easy to add additional delay, i meant the delay which is created due to mixing the signals. i did not recognize this for now which should result in a phasing. but the "long delay" from the plugins is allready correctly compensated.

> what is cool about using non signal connection for signals is that you can make themn "incompatible" with each other.

hehe some kind of type save audio stream huh :D - makes sense.

however, to build that graph handling with the delay compensation in max is indeed complicated. that is a problem where i would definitely shift to some procedural programming language, because this kind of problem is not something what max is made for i think.

"The place where you need to do the delay compensation is the input of a node. here you have to mix several signals, each signal has a delay. so you must calc the max delay and subtract the delay of the individual signal."

that´s the "normal" way of PDC like in a summing mixer and is exactly what does not work as soon as parallel branches come in the way... or it would mean that you have 10 delay obejcts in every node, which is what i´d like to avoid.

imagine you would like to extend it to 50 plug-ins, then you need 2500 delay objects.

and calculating the delay times is also not becoming easier, it is always the same.

what would be cool would be an algorithm which 1. checks your graph for serial/parallel connections and 2. checks which plug-ins have a latency of 0 and not 0, and then enables delay compensation only for those nodes who need it.