core mulitple to one

gentleclockdivider

Why is this not working ?

Input is a fader range 0-7 with increments of 1 , going into multiple comparisons signs

The output should give me the values going into the merge module( according to the input position ) , iow just like primpary multiple to one

gentleclockdivider

Let's try write-read to get the values into the merge

Mind you , that this shouldn't even happen at audio

Still no succes , and I know I had these issues in the past but somehow I forget them

gentleclockdivider

I just remembered that an empty input at the merge solves the issue

gentleclockdivider

However , for pure event ( getting rid of the read-write modules ) I am back at square one
No luck , despite the merge having an empty input ,

Why ?

gentleclockdivider

Found it , just use the selinput to trigger the read

This is the biggest difference between core and something like pure data max , a value is ALWAYS stored when it goes into the right input of the module . left triggers what's in the temp. mem

colB

conditionals ( comparators with green arrow outputs) do not generate or pass events

constants only generate events at initialisation

these two things mean your first attempt cannot work.

Style wise, better to use Latch modules instead of naked OBC, makes it more readable.

If you really just need to select between a bunch of constant values, it might be simpler to use a core table. Then just use the select value to index the table.

(whether this is the way to go really depends on the wider context though)

gentleclockdivider

Ah core , I think it's the most intuitive thing ever

This doesn't work , using the sr.c as a trigger for the mem modules

Theway I read it(first screenshot ) , if input slider equals x , then route sr.c to the true output of the switch , whcich then triggers the mem .

This does work (screenshot 2 ) If inputslider =x , then route input slider to the true output of the switch , whcih then triggers mem module

And this doesn't work either , screenshot 3 It should be intuitive

The way I read this

If input slicer =x , then route the value (constant ) to the true output of the switch , into the write input of the mem .
The read of the mem is triggered by the slider (ward )
The debugging is also something which is not really helpull , altought the input value is uqual to the value of the comparitor , the switch just show 0
And if constants are only send during intialisation , what's the use of constant values at the input of the router if they can not be controlled dynamically ??

I'm aware I sort of encountered all of these issues in the past , then someone points out the correct procedure but after a hiatus I forget almost everything about core , which imho tells a lot about it's intuivity ( or lack off )

Rant over :)

and again , this one (last screebshot does work too where the mem values are just stored values triggered by the fader , then going into route

colB

You first pic:

SR.C events are all synchronous with the audio clock… aka 'audio events'

Audio events cannot pass through a regular orange 'event port' (terrible naming scheme - you would expect 'audio events' to be some subtype of 'event')

if you change your output port to audio, then it will work (at least if it fails it will be for some other reason), but will sent a stream at audio rate rather than just single events.

What you would need is the third option, event type but with 'allow audio events' ticked in the port properties:

See the output port now has two overlapping circles a white 'audio' one and an orange 'even one.

The problem here is that it is just much slower, so best avoided where possible.

Better is, where possible, redesign the system so that you don't need to send single events out to primary that are synchronous with the audio clock.

This is all fundamental RTFM stuff, basic fundamentals of the language. The complexity is due to the transition to Primary - it's not a 'core problem' FWIW. Back in the day, we had two types of core cell, and things were somewhat more difficult ;)

colB

Third pic.

Again, fundamental stuff.

Routers route events, they don't generate them

compare modules don't generate events.

Constants only generate an event during initialisation, after that they don't…

So in your third pic, there are no events for the routers to route (except during initialisation, when the comparison result is likely false for all of them).

So whatever values (probably all zeros) gets to the latches at init time stays there and never changes. Then each time a 'ward' even fires, it drives all the latches to output their static unchanging value. These all hit the merge at the same time (they are all driven by the same source event 'ward'), so only the bottom one is used, the others all discarded.

So if at initialisation, ward fires a value of 7, then the initial output will be zero, then it will always be be 0.4954 after that. If ward doesn't fire at init, or it's value is not 7, then the output will always be zero.

colB

The last pic:

This works, because the constant values are latched to the fader input, so you get events to route.

It's probably less efficient than the approach from the second pic though, because you are firing all the latches every time, while in the second pic, you are routing the driving event 'ward' prior to the latches, so it only fires the 'correct' latch, and leaves all the others alone.

I say 'probably' more efficient, because the core compiler is an optimising compiler, so might find ways to sort out the difference, depending on the context, so it could potentially even generate the same binary code from both patterns… possibly, depending on the context.

2nd pic is the way to go, if the 'selector' type of approach is the best fit.

KoaN

I am not an expert but for me the thing important to remember is when using a core router the value needs to get pushed through so obviously constants and fixed value won't work by themselves,not the same as an audio stream.Once you know this things are fine i think.It can be a bit misleading at first when you are used to primary which behaves a bit differently.

gentleclockdivider

Yes ,router needs values need to be pushed through , in that regard it's no different like other data flow programs like pure date , which I believe are a lot easier to use ( when it comes to dataflow )

gentleclockdivider

Using the table approach in core is indeed much more fluent

Compared to