a core cell that responds to clicks but not clocks

alvacouch

I'm puzzled.

I'm trying to create a core cell that implements a simple MIDI follower.

Screenshot 2023-01-25 114558.png

It works when I assign "step" to a button, but not when I drive "step" with a clock at a modified control rate. Any ideas as to why? I think I'm missing something major!

Thanks,

alvacouch

I think I figured this out. See

Screenshot 2023-01-26 175223.png

It was most likely a compiler error. I revised the code for single event propagation paths and it works fine.

What this does is to smooth out sudden jumps in value on a touch panel by interpolating from the previous value at 10 steps per second.

colB

It's not a compiler error. That's not really a thing with Reaktor. If it compiles then it should do what you told it to. The problems arise when what we tell it to do is not what we expect and want it to do!

It's hard to debug from a pic where there are no external details - e.g. your structure will not work correctly with a knob in range 0..1, and will be poor with a knob in 0..1000, but might be ok in the range 0..127...

Also I notice that there is at least one strage thing

This int latch only activates when the current value in the OBC equals target... but it's the current value rounded to an integer... so if the input value is always an integer, the latch is redundant because it only ever writes the value that's already there, whereas if the input (and/or the target) can be some non-integer value, then this does something else maybe not what you expect...?

Also note a couple of connections from a Reset source that doesn't exist, but that shouldn't make the whole thing fail...

To understand why it doesn't work as expected, we would need to know more about the external context.

alvacouch

Thanks a bunch.

I've done a lot of work on it since then.

The context is midi signals with values 0-127, all integers. It's a smoother for the LK Android MIDI control surface, which avoids annoying jumps in fader signals when one's finger is not precisely where one wants it!

I've done a lot of work since my last post. The current version, which does exactly what I want, is this one:

The point is to follow the integer MIDI signal, changing by +1 or -1 at a fixed clock rate.

If there's any way to make this more efficient, I'd be very appreciative!

The context in which this is used is a fader bank controller, with 8 faders, to wit:

The point of this structure is to share a clock. Empirically, the best clock rate is 200 cycles per second.

The insides of the large item are excerpted as follows:

Each one of these "MIDI smoother" cells is a copy of the first cell above.

Thanks a bunch for the detailed answer. I worked in the interim enough to figure it out, but the detail in the answer is exceptionally good and helps my understanding greatly!

colB

https://community.native-instruments.com/discussion/comment/50560#Comment_50560

Audio was an issue, but not the only one. I changed everything to audio and it still doesn't work.

I didn't say you should change it all to audio IO. I said to change the ioutputs to "allow audio events". So they would still be event outputs, but those events can be synchronous with audio events - thats the only way you can output events that originate from the CR clock within the core layer.

Using pure audio IO to and from core cells is a hassle because its a constant stream at audio rate, so you have to handle it carefully to avoid inefficiency, and potential bugs

colB

https://community.native-instruments.com/discussion/comment/50864#Comment_50864

The context is midi signals with values 0-127, all integers. It's a smoother for the LK Android MIDI control surface, which avoids annoying jumps in fader signals when one's finger is not precisely where one wants it!

Ah, so do you mean that both the input and the output are MIDI 'signals'?

I suppose the main thing to watch out for in that context is the 'range' setting in the properties for the various MIDI modules. This defaults to and 0..1 range, if you want full 0..127 range, you maybe need to explicitly set that... or at least check it :)

Generally though, as long as its working, and the cpu meter is not complaining, I wouldn't worry about trying to optimise. That's a deep can of worms, and best avoided unless there is an actual problem!

colB

The clock generates Audio Events (at least audio synchronous), so you would need the outputs to 'Allow Audio Events'. There may be other issues too, but that's the obvious one looking at the pic.

alvacouch

Audio was an issue, but not the only one. I changed everything to audio and it still doesn't work.

The library function Core --> Library --> Control --> Smoother --> Lin Smoother (A) does something very similar but enjoys a complete lack of race conditions, unlike my example. It doesn't do quite what I want, but is close. I don't quite get why it works and mine doesn't. Will continue studying.

The most obvious difference between my solution and Lin Smoother (A) is that mine has a race condition between the target and current value as far as reading them out of memory. This could be the problem.

alvacouch

A related question: I think this core cell is failing to compile, but I have no evidence of why. It is not doing anything at all.

Is there any place I can check in Reaktor for core cell compilation errors?

alvacouch

I think I figured this out. See

Screenshot 2023-01-26 175223.png

It was most likely a compiler error. I revised the code for single event propagation paths and it works fine.

What this does is to smooth out sudden jumps in value on a touch panel by interpolating from the previous value at 10 steps per second.

colB

It's not a compiler error. That's not really a thing with Reaktor. If it compiles then it should do what you told it to. The problems arise when what we tell it to do is not what we expect and want it to do!

It's hard to debug from a pic where there are no external details - e.g. your structure will not work correctly with a knob in range 0..1, and will be poor with a knob in 0..1000, but might be ok in the range 0..127...

Also I notice that there is at least one strage thing

This int latch only activates when the current value in the OBC equals target... but it's the current value rounded to an integer... so if the input value is always an integer, the latch is redundant because it only ever writes the value that's already there, whereas if the input (and/or the target) can be some non-integer value, then this does something else maybe not what you expect...?

Also note a couple of connections from a Reset source that doesn't exist, but that shouldn't make the whole thing fail...

To understand why it doesn't work as expected, we would need to know more about the external context.

alvacouch

Thanks a bunch.

I've done a lot of work on it since then.

The context is midi signals with values 0-127, all integers. It's a smoother for the LK Android MIDI control surface, which avoids annoying jumps in fader signals when one's finger is not precisely where one wants it!

I've done a lot of work since my last post. The current version, which does exactly what I want, is this one:

The point is to follow the integer MIDI signal, changing by +1 or -1 at a fixed clock rate.

If there's any way to make this more efficient, I'd be very appreciative!

The context in which this is used is a fader bank controller, with 8 faders, to wit:

The point of this structure is to share a clock. Empirically, the best clock rate is 200 cycles per second.

The insides of the large item are excerpted as follows:

Each one of these "MIDI smoother" cells is a copy of the first cell above.

Thanks a bunch for the detailed answer. I worked in the interim enough to figure it out, but the detail in the answer is exceptionally good and helps my understanding greatly!

colB

https://community.native-instruments.com/discussion/comment/50560#Comment_50560

Audio was an issue, but not the only one. I changed everything to audio and it still doesn't work.

I didn't say you should change it all to audio IO. I said to change the ioutputs to "allow audio events". So they would still be event outputs, but those events can be synchronous with audio events - thats the only way you can output events that originate from the CR clock within the core layer.

Using pure audio IO to and from core cells is a hassle because its a constant stream at audio rate, so you have to handle it carefully to avoid inefficiency, and potential bugs

colB

https://community.native-instruments.com/discussion/comment/50864#Comment_50864

The context is midi signals with values 0-127, all integers. It's a smoother for the LK Android MIDI control surface, which avoids annoying jumps in fader signals when one's finger is not precisely where one wants it!

Ah, so do you mean that both the input and the output are MIDI 'signals'?

I suppose the main thing to watch out for in that context is the 'range' setting in the properties for the various MIDI modules. This defaults to and 0..1 range, if you want full 0..127 range, you maybe need to explicitly set that... or at least check it :)

Generally though, as long as its working, and the cpu meter is not complaining, I wouldn't worry about trying to optimise. That's a deep can of worms, and best avoided unless there is an actual problem!

alvacouch

https://community.native-instruments.com/discussion/comment/50983#Comment_50983

Done. I also modified the signals to be Events that allow Audio events with no change in function. Thanks a bunch!