Comments (6)
From [email protected] on June 24, 2013 16:47:19
This is actually already returned via the RDM model collector, although it's not exposed on rdm.openlighting.org, so I assume it's that side that needs updating to use it.
However it's currently returned in a root node, given this presumably varies by DMX personality (I assume what you mean by "hardware profile"), perhaps it should switch to being returned within the DMX personality the fixture is currently in. With some processing on the rdm.openlighting.org site end if desired to just return an overall status about sub devices on the fixture.
from rdm-app.
From [email protected] on June 24, 2013 20:10:43
Ah I didn't realize it was already reported. It may be good though to run the same collection process for the subdevice since they can support different pids from the root device.
By 'hardware profile' I was referring to how the number of sub-devices can change based on the modules that are installed (in the dimmer rack case). So absolute number isn't so important, rather we want to know if the device has sub devices or not.
from rdm-app.
From [email protected] on June 24, 2013 20:25:08
Yes, from what I read, it seems we should get things like supported pids from the sub-device, as it may differ compared to the main device.
Okay, but what about DMX personalities? To take a real world example I'm aware of, from pre RDM days, a Pixelline can be configured via its menu to a number of profiles, from one "cell" RGB control across the whole device, to ten cells, each with RGB control. In an RDM world, firstly would/could they be implemented as sub-devices, so they could be individually identified and addressed? If so, then presumably the number of sub-devices can change when you change personality? What about different channel layouts with different personalities, e.g. RGB versus Dimmer, RGBAW, Strobe; I guess that's less of an RDM thing?
from rdm-app.
From [email protected] on June 24, 2013 20:47:03
The 'correct' way to do that with RDM would be for each pixel to be it's own sub device (and hence have it's own personality). The number of sub devices really shouldn't change with the root device's personality.
from rdm-app.
From [email protected] on June 25, 2013 11:29:50
That sounds like it covers if the cell changes from RGB to Dimmer, RGBAW, Strobe for example, but what about for changing the number of cells, so going from one set of controls for the whole fixture, to individual control over each cell? Or would you be expected to patch each cell's sub-device to the same start address?
Although I see the DMX personality description returns the number of channels needed, so presumably that should be fixed and not interdependent with sub device personalities.
from rdm-app.
From [email protected] on June 25, 2013 22:26:50
Or would you be expected to patch each cell's sub-device to the same start address?
Yes, this can be done with a single command addressed to the 'ALL SUBDEVICES' target.
from rdm-app.
Related Issues (20)
- Add a reciprocal link to Open Fixture Library fixture profiles
- API Content-Type HOT 3
- Use Google Cloud Storage rather than Blobstore for images HOT 2
- Manufacturer PIDs HOT 4
- Catch and block "could not connect" error in manufacturer data generation script
- MANUFACTURER_MODEL_COUNTS memcache doesn't get cleared during responder moderation HOT 1
- Add labels to slot_label_id for SLOT_INFO HOT 2
- Add more manufacturer PIDs HOT 3
- Fix an upstream spelling mistake HOT 2
- Make manufacturer names be ordered case insensitively
- Display collected manufacturer PID data
- Add Sauce Labs for the JS tests
- Add a CSS Linter HOT 1
- Port/Convert Manufacturer PID data to RDM Schema HOT 1
- Please push the queue in rdm.openlighting.org/admin HOT 3
- A missing manufacturer entry confuses responder moderation
- Don't delete manufacturer IDs
- Fix 0999h where Company is blank but Organization Name(Textual Organization Identifier) is populated HOT 1
- Don't allow duplicate manufacturer IDs to be imported HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from rdm-app.