forgot to mention: the Merge node in the above example for now does HTP only.
and here a specific question: it seems to me that the mergemode (HTP, LTP, …) would be a property of a channel. but when looking at 2 different fixture description formats, one (R20) had them for channels, the other one (D4) not. where else would you want to specify the mergemode than as a property of a channel?
Well, dimmer is the only thing that should really be asked to be htp
Maybe creating 2 merger, 1 htp 1 ltp and picking inside the htp in a kind of setslice ?
Btw there is one thing thzt diseappeared from art net nodes: possibility to change the udp default port 6454 to something else ( input and output being different)
This is necessary when using 2 softs using artnet qnd sending artnet to other soft, on same computer
@karistouf please start a new thread if you’re saying that the commandline-parameters to change artnetports do no longer work for you.
@joreg > never noticed it was changed to command line. would have been better to have it in the pin of the node, like it was a few year ago
@karistouf am afraid it never was a pin. we only later added the commandline-option because it was easier to add than a pin.
Still haven’t had a chance to look at this, or VL since node, but I would request, that art net have better performance, having for example 40+ DMX nodes takes the frame rate right down (the most I’ve tested), we should be able to send unto 256 universes, this is possible with lighting software, and is necessary if your using a lot of LED’s
I know ALS has a multithreaded art net node, it would be good to have such a thing natively, or will suing raw UDP allow that? There are a few projects I’ve backed away from due to the universe counts…
@joreg regarding interface I was refering to a VL language feature that you may have mentioned in a presentation some time back, maybe at Resonate. Quoting DotNetTricks
What I understand from that is that a class of ‘fixture’ could be made and what and how features of fixture objects are accessed maybe based on this interface. The interface could perhaps say (true/false) if it is a moving head, 3, 4 or 5 color rgb, has frosting, has particular gobos, etc.
What happens further down I’m not sure yet but I was wondering if using an interface improves structure or adds flexibility. I dunno maybe its a useful in this circumstance, maybe its overkill.
@Kalle and @Kari while I appreciate the apprehension about enums, I think its potentially a more straightward system than a lot of nodes, even if spreadable. You could have cleaner patch down the line. My personal preference would use something like the table for setting up the fixture list with channels and maybe some mode selections if available. The fixtures would be added to the universes (and potentially a visualiser).
On the controls side I tend to build as needs must. Working with a desk is very fast for a lot of jobs so I think that its worth asking what would we like to do that a desk can’t do and what would you like bring into a dmx framework that a desk can? Do you want to patch a whole show or design tools for certain effects that plug into a more generalised system?
I think that grouping/soloing, timelining and show pages will always be important, but we should try to avoid following the conventions of desks slavishly.
@Cat agreed.
hey, we hear you all about missing features and performance of the dmx/artnet nodes. but i’d like to keep that thread on the initial topic…
@guest: regarding interfaces in VL: yes, they’re coming. yes, they could be used in the implementation of such a framework, but implementation-details should not be our worry here/now.
@other guest (or same?): yes, visualizer can easily be part of that framework as well, but would also not consider that the first step…
right, maybe that would have been the better question. we were merely thinking that joining/merging fixtures to a universe would be the most basic think someone would want. still hoping for comments on our last proposal. or is it simply not remotely interesting and we should scratch that?