Maximum amount of universe or parameters

[lightingop]

I am using MidiMonster 3.0 on Windows 10 64 bit. I am wondering what is the maximum amount of parameters or universe MidiMonster can handle. I'm trying ton convert 36 SACN Universe to 36 Artnet universes send to individual lighting fixtures. Best I could do is 7 Universes whitout MidiMonster crashing. I'v attached my current working config.
Thank you
monster.pdf

[cbdevnet]

Hi, thanks for your interest in the MIDIMonster and thank you for the report.
I've not done proper performance limit testing yet, but at least on Linux with a decent laptop I have gotten on the order of 100 ArtNet universes working.

I pushed some updates to the ArtNet and sACN backends these last days and will probably release a v0.4 in the next few days. That includes some rate-limiting that should have been part of those backends for a long time.

There may be some additional difficulties in running larger translations with Windows, as the network APIs are different. I'll try to look into that after 0.4 is out, until then I'd invite you to test with 0.4 once its out :)

Thank you for providing an example configuration, I'll try to reproduce the problem here, too :)

[lightingop]

@cbdevnet Thank you for the quick answer.
I also tried it on Linux Ubuntu Server on a pretty decent computer. I run the already built package for linux. For the same config file It is more laggy on my Ubuntu server. It keeps logging: "artnet Failed to output frame for instance artnetX: Ressources temporarily unavailable"

Is there something wrong with my config file or could it be simpler since I just want to convert full universe one protocol to another?

[cbdevnet]

I think the configuration is pretty OK, with 0.3 the amount of data output depends a lot on the number of channels that change, because there isn't a lot of "combination" going on yet. With the new rate-limiting commits to the ArtNet and sACN backends of the last few days, the transmit limit of about 44 packets per second that is recommended by the standard is kept, which carries with it the feature to combine multiple channel updates into one output frame.

The Ressources temporarily unavailable message most likely is the kernel alerting the MIDIMonster that the transmit buffer for the network is currently full (ie, it's transmitting too much data at once). The new patches should alleviate that a bit, I'll also look into making that buffer bigger or ordering output frames in a way that permits more throughput.

To be fair, the last time I've done any amount of testing that went to the limits is a fair bit back when much of the core code was simpler. With a few thousand channel mappings, probably the internal channel routing code is exercised quite a bit, I might have to look into that fairly soon again as there is probably a lot of optimization potential in there.

[lightingop]

ok Thank you. I'll wait for updates then :)

[cbdevnet]

Commit 04494e4 changes the ArtNet and sACN backends to use local channel stores, as basic profiling showed that the core spent an inordinate amount of time searching the global channel registry.

On my old i5, the following configuration and script (which is just spamming random values out on 8 universes every 10 milliseconds) uses about 60% CPU and generates 400 packets per second. Most of the time is spent routing events (mm_channel_event), which is another huge optimization target I'll be tackling soon.

Configuration:

[backend artnet]
bind = 0.0.0.0

[backend sacn]
bind = 0.0.0.0 5568 local

[artnet a1]
dest = 255.255.255.255
universe = 1

[artnet a2]
dest = 255.255.255.255
universe = 2

[artnet a3]
dest = 255.255.255.255
universe = 3

[artnet a4]
dest = 255.255.255.255
universe = 4

[sacn s1]
priority = 100
universe = 1

[sacn s2]
priority = 100
universe = 2

[sacn s3]
priority = 100
universe = 3

[sacn s4]
priority = 100
universe = 4

[lua generator]
script = generator.lua

[map]
generator.out{1..512} > a1.{1..512}
generator.out{1..512} > a2.{1..512}
generator.out{1..512} > a3.{1..512}
generator.out{1..512} > a4.{1..512}
generator.out{1..512} > s1.{1..512}
generator.out{1..512} > s2.{1..512}
generator.out{1..512} > s3.{1..512}
generator.out{1..512} > s4.{1..512}

generator.lua

function generate()
	for chan=1,512 do
		output("out" .. chan, math.random())
	end
end

interval(generate, 10)

[lightingop]

I tried this new version on windows. Thank you for that great update.

I still have issue which I investigate more. Depending on how many values are changing at the same time artnet output slow down or stop, but the software is not completely crashing. When I send 20 packet/s by universe with Resolume Arena playing a video that have a lot of black (so the values are not all changing at the same time) MidiMonster is also able to output 20 packet/s. Even there, prompt window keep logging "Instance X not enable for output (0 channel events)" With some video I could have at best 6 packets/s by universe. With a stroboscope video which is basically turning on and off all the value , artnet is just stopping but CPU usage is only 44%.

I made a test config which is only for test purposes. I am monitoring artnet with Artnetominator software.
`[backend artnet]
bind = 0.0.0.0

[artnet a1]
net = 0
universe = 8
[artnet a2]
net = 0
universe = 9
[artnet a3]
net = 0
universe = 10
[artnet a4]
net = 0
universe = 11
[artnet a5]
net = 0
universe = 12
[artnet a6]
net = 0
universe = 13
[artnet a7]
net = 0
universe = 14
[artnet a8]
net = 0
universe = 15

[artnet artnet1]
net = 0
universe = 0
destination = 2.255.255.255
[artnet artnet2]
net = 0
universe = 1
destination = 2.255.255.255
[artnet artnet3]
net = 0
universe = 2
destination = 2.255.255.255
[artnet artnet4]
net = 0
universe = 3
destination = 2.255.255.255
[artnet artnet5]
net = 0
universe = 4
destination = 2.255.255.255
[artnet artnet6]
net = 0
universe = 5
destination = 2.255.255.255
[artnet artnet7]
net = 0
universe = 6
destination = 2.255.255.255
[artnet artnet8]
net = 0
universe = 7
destination = 2.255.255.255

[map]
a1.{1..380} > artnet1.{1..380}
a2.{1..380} > artnet2.{1..380}
a3.{1..380} > artnet3.{1..380}
a4.{1..380} > artnet4.{1..380}
a5.{1..380} > artnet5.{1..380}
a6.{1..380} > artnet6.{1..380}
a7.{1..380} > artnet7.{1..380}
a8.{1..380} > artnet8.{1..380}`

[cbdevnet]

Hm, 20 packets per second sounds very low, it might be that Windows sockets have some additional limits, I'll try to find a Windows computer to test that.

[lightingop]

Well it's 20 packets by universe so that is making 160 packets by seconds total