heronarts / lx Goto Github PK

This makes for zero effort import into IDEs and makes for easy publishing of jars which makes importing LX into a project much easier. I'm happy to do this work if you will consider merging it.

This line ensures a tempoLocked LXPeriodicModulator will always have a basis <1:

After this, looped is set if the basis is >= 1.

Click relies on boolean loop() to compute a value of 1 and thus, to .click()

Therefore, while a tempSynced Click will .click(), if it's also phase locked to global tempo, it will not.

I'm not confident enough on the effects on other modulators to submit a PR, but I wondered what you'd think of changing:

to:

this.basis = rawBasis;

and leaving the basis >= 1 condition to be handled in:

This might be by design, so feel free to close it if so.

LXMasterBus has its model field set right on startup, and the field isn't updated when the model updates, either through loading a new project or adding new fixtures, and so the model.points array remains empty. Any effect that works by iterating over this.model.points doesn't work on the master bus because it never receives the model points.

Fine to work around by just iterating over colors[], but raising this because it might also break other things.

Can reproduce by putting AppEffect from the LXStudio-IDE distribution on the master bus.

Cheers!

To reproduce:

• Set Tempo clock source to INT
• Turn on OSC output
• Turn off OSC output
• /lx/tempo/beat messages continue to send

What is the colloquial way to transfer freshly built LX libs for use with LXStudio?

I've just been doing (from root of LXStudio project, assuming LX and LXStudio adjacent):

cp ../LX/target/lx-0.4.1-jar-with-dependencies.jar ../LX/target/lx-0.4.1-javadoc.jar ../LX/target/lx-0.4.1-sources.jar ../LX/target/lx-0.4.1.jar lib

.. because these *.jar are indexed by git this seems like a bloated way of doing this, rather than a reference.

It would be nice to have a getMediaPath() call so I don't have to use reflection to get access to the private variable. The root cause, actually, is only being able to use a File and not an InputStream when playing audio programmatically.

My workflow is to create a temporary file in the mediaPath directory, using java.nio.Files.copy() to copy the contents from an InputStream, and then starting the audio.

The core reason mediaPath is needed is because it's used as the root directory internally.

When the APC40 is first enabled, the LX channel faders are synced to the APC40 faders and the APC40 channel on/off lights are synced to the LX channel on/off status.

If a channel is deleted from any position other than the last, or a group is created, the faders and on/off (and A/B) lights get out of sync. I think the fader behavior is fine, because syncing them immediately would mean a user couldn't delete a channel during a live show without causing all the other channel faders to jump. For the lit buttons, I think it would make sense to refresh them on the APC40 so they are always correct. This includes the channel on/off, channel A/B, and the lit grid of buttons tied to patterns (indicating available, currently running and currently selected pattern).

Again I think this is low priority, because most channel setup happens once and then people don't mess with it.

In the past, I would build a model via extending LXModel, adding some points, etc..

Now we can graphically do this and/or via a json file(Awesome work @mcslee!). That said, I still prefer to build things programmatically.

Poking around I see that there is lx.structure.LXBasicFixture where the GridFixture comes from.

Then to add these to the fixture drop down, these are added to the LXRegistry as an array of default fixtures.

So question:
Is there a recommended way to generate a model these days?

Currently building out the trees for www.github.com/follybuilders/paradisium

I've got some logic for indexing and cataloging patterns and channels that happens when a new project file (.lxp) is loaded.

Right now, this setup sometimes explodes because the channels aren't created yet.

Other than wrapping code like this in an exponential backoff:

while ( ... ) {
  try {
      lx.engine.mixer.channels.get(EFFECTS_CHANNEL_INDEX_INT_HERE);
      // ...
  } catch (IndexOutOfBoundsException e) {
     // double the wait, and try again
  }
}

are there any good hooks for putting said initialization code into?

I think initialize(LX lx) is only run on UI start, not project load, and therefore is also before the mixer is fully loaded with channels specified in the .lxp

When tempo.clocksource is set to OSC, it appears tempo is still ramping at the speed set by tempo.bpm. For example, if tempo.bpm is manually set to 20 with the ui, and the external source driving OSC beats is running at 80 bpm, then tempo.ramp will only reach a value of .25 between beats.

Also, if the bpm is set to a higher frequency than the external OSC source, then an extra beat fires between every external beat. The timing of this beat is (1/tempo.bpm) seconds after the external beat. In this case tempo.ramp starts at 0 on the external beat, increases at the tempo.bpm rate until it reaches 1, then the extra beat fires, then tempo.ramp remains at 1 until it is reset by the next external beat.

This looks like two items to fix:

1. When tempo.clocksource is set to OSC, only fire a beat when it is received from the OSC source. Don't fire based on time elapsed since the last beat.
2. When tempo.clocksource is set to OSC, calculate tempo.bpm and tempo.ramp on a continuous basis based on timing between OSC beats.

Alternatively for item 2, an external source that already knows the bpm could pass the bpm value as an additional OSC parameter and save LX from doing a redundant calculation.

When a delete channel action is undone, selection should be removed from the currently selected items at some point in the process. [Or maybe more logically/specifically, the invisible action of auto-selection that happened after the delete should be undone prior to undoing the delete.] Steps to reproduce the problem:

1. Add a few channels.
2. Delete a channel(s) or group(s). Note that the item was selected before it was deleted.
3. [Upon deletion, a neighboring channel is selected. This could also be a group or the Master channel.]
4. Cmd+Z to undo the delete.
5. [The item reappears and is selected.]
6. [Now everything that was selected before and after the deletion is selected. This could be a combination normally not allowed to be selected, such as a Channel + Group, or a Channel + Master.]

Hi @mcslee, first of all thanks for all the awesome work you're doing with LX/Chromatik.

I'm working on some audio patterns for Titanic's End, I believe you're familiar with some of the folks involved.

When I’m piping stereo input into LX (using Soundflower or Loopback), particularly if I'm switching between audio input sources in the LX UI, I’ve had a couple of intermittent issues where my sound suddenly stops and I get an error popup saying: Cannot enter synchronized block because "this.inputThread" is null

It seems to go away when I restart LX, but it’s happened a couple times now. The stack trace is coming from LX code, so I figured it was worth mentioning here in case you or other LX users have run into anything similar.

• Platform: m1 MacBook, JDK Temurin-17
• LX Version: 0.4.5-SNAPSHOT
• The code path where we're sampling the audio happens here, through a standard GraphicMeter: https://github.com/titanicsend/LXStudio-TE/blob/main/src/main/java/titanicsend/pattern/yoffa/shader_engine/PatternControlData.java#L14

Here's the full stack trace:

java.lang.NullPointerException: Cannot enter synchronized block because "this.inputThread" is null
	at heronarts.lx.audio.LXAudioInput.start(LXAudioInput.java:212)
	at heronarts.lx.audio.LXAudioEngine.onParameterChanged(LXAudioEngine.java:91)
	at heronarts.lx.parameter.LXListenableParameter.setValue(LXListenableParameter.java:222)
	at heronarts.lx.parameter.LXListenableParameter.setValue(LXListenableParameter.java:205)
	at heronarts.lx.parameter.BooleanParameter.setValue(BooleanParameter.java:70)
	at heronarts.lx.parameter.BooleanParameter.setNormalized(BooleanParameter.java:93)
	at heronarts.lx.parameter.BooleanParameter.setNormalized(BooleanParameter.java:24)
	at heronarts.lx.command.LXCommand$Parameter$SetNormalized.perform(LXCommand.java:588)
	at heronarts.lx.command.LXCommandEngine.perform(LXCommandEngine.java:60)
	at heronarts.glx.ui.component.UIButton.setActive(UIButton.java:498)
	at heronarts.glx.ui.component.UIButton.setActive(UIButton.java:477)
	at heronarts.glx.ui.component.UIButton.onMousePressed(UIButton.java:424)
	at heronarts.glx.ui.UIObject.mousePressed(UIObject.java:624)
	at heronarts.glx.ui.UIObject.mousePressed(UIObject.java:598)
	at heronarts.glx.ui.UIObject.mousePressed(UIObject.java:598)
	at heronarts.glx.ui.UI2dScrollContainer.mousePressed(UI2dScrollContainer.java:241)
	at heronarts.glx.ui.UIObject.mousePressed(UIObject.java:598)
	at heronarts.glx.ui.UIObject.mousePressed(UIObject.java:598)
	at heronarts.glx.ui.UIObject.mousePressed(UIObject.java:598)
	at heronarts.glx.ui.UI$UIRoot.mousePressed(UI.java:153)
	at heronarts.glx.ui.UI.mouseEvent(UI.java:1007)
	at heronarts.glx.InputDispatch.dispatch(InputDispatch.java:230)
	at heronarts.lx.LXEngine._processInputEvents(LXEngine.java:982)
	at heronarts.lx.LXEngine.processInputEvents(LXEngine.java:958)
	at heronarts.lx.LXEngine.access$1600(LXEngine.java:63)
	at heronarts.lx.LXEngine$ExecutorService.lambda$start$1(LXEngine.java:652)
	at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539)
	at java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305)
	at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:305)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
	at java.base/java.lang.Thread.run(Thread.java:833)

When the MidiFighterTwister is used as a generic midi surface with user-created midi mappings, the encoders are still sending relative position changes which are midi values (61, 62, 63, 65, 66, or 67). The generic midi mappings are not aware of the relative encoder setting and are interpreting these as absolute midi values. Turning a mapped knob sets the target parameter to a normalized value of (usually) 63/127 or 65/127.

This is a handy widget! it would be cool to add a visual aid so that it's clear what color is represented by the 3 parameters. One thought is to group them and make their background the currently selected color..
I realize at least part of this implementation would happen in P3LX..

Hi Mark - thanks for putting extra code in for the DDP packet issue I ran into.

I am wondering if you really want to go this direction, framework-wise. By simply exposing "push" and allowing data offsets, the application code has to know the underlying network transport packet size, which I consider more of a framing issue.

If, instead, LXDatagram has a list of the packet field, and called socket.send() on each of them in order, that would seem to allow an individual LXDatagram subclass to have multiple packets.

Alternately, exposing a method for 'send' which is default mapped to socket.send() but could be overridden would seem efficient.

I believe this creates complexity in setting RGB values for Output, too, but I haven't thought through that.

As a final thought, a very simple hack would be to expose a "maximum size" on LXDatagram that allows application code - which, now to be transport independent, has to always include a loop to generate multiple datagrams, in every application with the new scheme - but at least could use a value exposed by the LXDatagram , who knows about its own framing and protocol problems.

As you know, Squared supported both FadeCandy ( OPC via TCP, no frame problems ), so I just keep thinking about how groovy LX is as a framework, how it comes with a lot of "stuff", and one of those things is Output....

I am also considering whether to avoid the problem by adding another NDB. I've got a ton of workarounds, I'm just thinking out loud about your framework....

Food for thought.... and I'm still evaulating the shift from the pre-LX Studio world to the LX Studio world.... still a matter of time and energy....

Currently in LX studio, I can only record and store 5 clips per channel.

Is there a way to hold more? I don't mind if they aren't always visible, just want them to be programmatically available.

The work around is to just create a bunch of channels to keep holding more but that's kind of hacky.

Another color oddity documented by @jvyduna. To reproduce:

• Set master swatch color 1 to: oscillate, HSV, from hsb(160,100,100) to hsb(200,100,100)
• Set master swatch color 2 to: fixed hsb(0,100,100)
• Add Gradient pattern: HSV2, Palette, 2 stops

As color1 oscillates the gradient snaps between two shortest HSV2 routes, causing a visual glitch.

As far as I can tell the osc address == component addres + / + parameter path?

Essentially, I'm hooking LX up with TouchOSC and would love to set address for parameters per pattern kind of thing - i.e.

public final BooleanParameter foo =
 new BooleanParameter("foo")
        .setDescription("Left handed spiral")
        .oscAddress("/foo/bool/1");

Kind of thing..

If the velocity parameter in an Accumulator returns zero, the Accumulator should sit at current value and not increase. Instead it goes infinite loop and freezes the UI.

https://github.com/heronarts/LX/blob/dev/src/main/java/heronarts/lx/modulator/Accumulator.java#L74

As you can see here:

I can't set this lower than 100ms. Is there a reason for this?

Occasionally and event happens, and I'd like:

LXPattern newPattern = ...;
currentLXChannel.goPattern(newPattern);
LX.log(curChannel.getActivePattern())  // should return newPattern, but instead still returns old one b/c of 100ms transition time

The transition feature is nice, but sometimes I need to just do it instantly.

Wondering if there's a latency reason to have this (ie: LX can't transition faster than 100ms) or if this is just a simple change from 0.1 -> 0.0 in code.

I'm loving the new views feature, but I notice that when I define on in the "Model" pane, the view isn't there when I re-open the same LXP file.

For example, after defining a view like this:

I click "save" in the top of the UI, then close the project and reopen it, and the view list is empty again: