A new channel was added to the beat detection processor for configuring the quantum value.
Just noticed that attempting to resize windows doesn’t activate anything. Usually, clicking on the diamond shaped icon with the four arrows allows one to drag the new windows to resize them.
Also, when I first click on a new NDI input the space jumps to the next page. Then I scroll back and choose the NDI input again.
mute the sound
video of NDI jumping position
Is there a way to undo current Highlight/Lowlight and/or Offset programmer value?
I mean for Offset, if you did a bad manipulation, and want to undo or simply cancel the edit, you can’t (at least, I did not found how to do it from NX1/K in 1249).
While in EDIT mode, you can clear HL/LL/offset values like you normally do in the programmer
Sorry, I was meaning you can not not save your modification.
I was having setting X, and did modification, finally I don’t want to save the modification to stay with setting X.
How can we cancel the edit mode without saving the modification? (undo doesn’t undo while in edit)
Indeed, it is applied directly, edit of those values (currently) doesn’t track changes within the session (to be rolled back)
I’m having issues with the 2D Plan and scaling
Setup: 16 Universes of Led Pixels + Moving heads.
Problem: 2D Plan zoom out is limited, so one can’t see all fixtures, while zoomed out completely. This happens with multiple projects of mine.
Goal: show the whole canvas in 2D Plan.
Tools fail:
- Alignment of fixtures always uses “default” fixture size and grid size.
- Reducing fixture footprint doesn’t adapt alignment tool distances between fixtures.
- Set 2D grid to finer grain, won’t reduce fixture spacing when using alignment tools
Three possible solutions:
- Extend Zoom Out Ratio
- Add Zoom Multiplier for Zoom In and Zoom Out to 2D Preferences.
- Alignment tools are aware of fixture size and grid size.
Quality of Life:
2D Plan in edit mode offers a way to re-deploy existing fixtures. This would be possible if 2D Plan edit mode fixture selection would sync to programmer fixture selection.
Hi Obsidian team!
A few bugs to share that have persisted through the 4.9 Betas –
• When running multi-console sessions, a fixture can only be Unparked using the console that it was Parked from. i.e; if a fixture is fully or partially Parked using a Secondary console, it cannot be Unparked from the Primary console.
• Very long boot time on NX4
• Show files typically take VERY long to load. This seems to be more of an issue in 1251 than the previous build.
• Xnet generally less stable than in 4.8. Many inconsistent issues of physical desks that are networked together not being able to join or push shows, playback falling out of sync, and sessions locking-up requiring network cables to be unplugged. This is a very serious and long-standing issue when running larger productions that demand have a networked backup console.
• User Experience for the new offset / park / default / highlight tools still needs some work. Would love to jump on a Zoom call with the dev team to share some more insightful feedback.
• (this may have been an issue in 4.6/7/8 as well - never had this use case before). Was running a show on an NX4 recently with 60 universes of pixel-mapping via DyLOS. At this scale, there were a few usability issues that creeped-up making it almost impossible to work with this many fixtures; many of which are related to the feedback shared by @astey. Furthermore, the Grouping tools simply could not compute with this many fixtures. For example, selecting 2000 pixels and filtering to “Blocks of 100” was impossible. It’s as if the command instructs the program to calculate “Block of 1 > Block of 2 > Block of 3” until it reaches the requested size, with each instruction taking exponentially longer to compute. There’s a definite code issue here.
• Occasional DirectX issues on NX1 and NX4 (even with a full fresh install). This presents itself with DyLOS-related interfaces not properly rendering on the screen, as we sometimes saw when DyLOS was first introduced.
Really loving the development we are seeing, but sympathize with the many users who would love to see some of the long-standing weaknesses carried-over from M-Series to be addressed before working on new features altogether.
1 Like
Another bug –
Presently preparing a show file for an event tomorrow and cannot batch-assign addresses to multi-part fixtures using the normal command line syntax. Specifically, I’m trying to address a bunch of Astera Hyperions in 32-pixel mode. The syntax “901 through 912 @ 1 / 2” is not working. No error or conflict; simply nothing happens. The same syntax works perfectly for non-multi-part fixtures. The only way to address multi-part fixtures seems to be one-by-one; i.e. “901 @ /2, Enter”, “902 @ /2, Enter” etc. Very tedious.
Thanks for the report, will be fixed in a future build
Network issues: do you also experience those when 2 consoles are connected using a direct cable (no switches) and with only XNet enabled on that connection?
DyLOS issue with 60 universe mapping: could you upload the show file to Obsidian Control Systems?
I’ll need to come back later on other topics
Sometimes I encouter this popup after closing Onyx:
"Startup Problem
A previous session of Onyx is still running and can’t be stopped. Restart Windows and try again."
Is there any way to launch Onyx without restarting the computer?
Hello @gert_leunen! 
Yes, I’ve had the same issue even with 2 physical consoles hardwired together through a passive network switch without any other devices on the network. There are a few different scenarios in how this presents itself:
- The consoles simply do not see one another. 1-or-several reboots of both consoles usually resolves this.
- The consoles see one another, but the “software version” field blinks “unknown” (or something similar to that) and will not allow the show to join, even though the software versions do match
- The consoles sort of see one another, except they only display as a large question mark (?) under devices rather than the illustration of the console, and will not allow the show to join.
- The consoles see one another and allow the show to join, but the show load takes 3-5 minutes, and - as soon as it completes - both consoles immediately revert to standalone mode
- The consoles see one another and allow the show to join, but the session becomes corrupt; ie: playback statuses stop syncing, the intensity readout on fixture tiles display “0%” regardless of actual output etc.
- The consoles see another and allow the show to join, but - intermittently - the session will lock-up. The touch screen interface completely freezes on the consoles, but physical faders continue to work. It’s not possible to enter the menu via the GUI to “leave” the show. The only solution is physically pulling the network cables and waiting. Usually within a minute the Primary console recognizes that it’s now on it’s own and will revert to Standalone operation. At the same time, the interface unfreezes and will usually flash through the backlog of button-presses very quick.
I’m trying (quite successfully) to push this platform on some large-scale and very high profile events in my city, and have also directly influenced the purchase of a number of NX4’s and NX1’s. Given the nature of many of these shows, it’s often required to have a live tracking backup, but Xnet continues to be so buggy that it’s making the platform less reliable than simply running only one console. I’d love to play a part in helping solve this for myself and other Onyx users who depend on this feature.
I also on an event last night using a fresh show file that it’s indeed not possible to manage parked fixtures from any console in a networked show; only the console that initiated the parking.
Re: the show with 60 universes of pixel mapping on an NX4; I’ll locate it today & upload via the link you provided. I’ll ping you here as soon as that’s done!
Have a wonderful weekend,
Rob
@gert_leunen - the requested show file has been uploaded and is named “JARDIN ROYALMOUNT - JUNE 25 WEDDING (JUNE 25, 2023)”
Warmly,
Rob
Another bug for the team - although I suspect this isn’t related to this Beta.
I’m presently exploring DMX merging for the first time in anticipation of an upcoming install, and am super impressed with the capabilities that Onyx appears to have in this regard.
As I work on a Proof of Concept, I’m using sACN between two Onyx PC setups; one representing the “house” system, and one representing a “guest” console.
I’ve patched a DMX Merger fixture and it appears to be pretty self explanatory. I’m using an sACN data viewer tool (“sACN View”) to study how everything works.
It appears that any time the “Input Weight” channel of the DMX Merger fixture is at any value other than 0 or 255, that the merged data flickers around pretty chaotically. I would have expected that the merged data could be “crossfaded” in a similar way that we observe with the “Direct Weight” channel.
When the “Direct Weight” channel is adjusted, the broadcast data is proportionately adjusted, but when the “Input Weight” channel is adjusted things go wonky unless the Input Weight is at 0 or full.
Any ideas or suggestions as to what may be going on?
1 Like
Gert please look at the show file with the SWAPPED FIXTURES “SONG STAGE” all the swapped fixtures when using the pan tilt FX stored in the preset Intensity section,when moving are “TREBLELING” they do not move in a smooth way! So this is a big problem. It shows this behaviour in capture 3d!,but I presume the same in real life,can you check please!
We’ll have a look at the parking issue across the network.
For the other networking issues, have you also tried without the passive network switch? Do all of your scenarios involve a common console (not just model, but actual physical console), network switch or network switch brand/model? From the behaviors you describe, I rather suspect a low-level network issue (like a failing network port, a failing network cable, or an unsuitable network switch - that has broadcast storm protection enabled, for example)
If you take all the RGB colors to zero then the color picker stops working. Bring one color back to 50 percent and then color picker starts working again.
Taking RGB colors to zero implicitly pulls the color intensity on the color picker to zero, which is why the color output doesn’t “generate visible output” while hovering the colors. Pulling up that intensity enables output again