how to save a core-latch in a snaposhot?

Bernd Scheurer

hello community,

i have taken the first successful steps at the core level. for example i have built a selector with more than 16 inputs, based on an array, that works fine. if i save a snapshot of the ensemble, the setting will be taken over.

now i have built a kind of counter with which i can endlessly choose between 8 different modulation sources with a plus- and a minus-button (trigger). similar to the "spin list-module" in the primary level. the core cell use latches and also works perfectly. but if i save a snapshot and call it up again, the latches in the counters didn't know the last value.

can it be that the core-selector only "knows" the last value because the knob at the pos-input was saved and the buttons on the counter do not have a fixed value because they only give +1 or -1 to their core cell? if so: is there a way to save the content of a core latch together with a snapchot?

thanks and best regards,

bernd

colB

You need to send new values out of core in to primary to a snap value module, or a snap value array, and wire that back to the input. Set the snap module so that 'thru events' are off.

This is a commonly used 'pattern' for core in my experience. It can get tricky to debug on occasion due to the boundary between primary and core complicating the init rules, but usually just works!

I have lots of Blocks and instruments that look a bit like this:

or this:

That first one for example is a clock divider, which has a gate mode, so it times the input clock... which means that it takes a couple of ticks to know how long to make the gate... so I save the gate in a Primary level Snap Value module, then it loads in on recall and all is well (assuming the timing will be the same as when the snapshot was stored...) seems to work a treat.

Second one is a monster, basically a huge system in a giant core cell, with a large data structure that gets stored in the snap value array. It seems to work ok, although there can be problems when editing. In that case, the resets behave a bit differently, so you can end up with incoherent data if the data structures is non-trivial... Best not to create patches or snapshots that matter while still in the regular dev process... That won't be a problem if you are only storing multiple individual values though...

Anyway, it's simple enough just make sure to turn off the 'Write Thru' parameter on the snap value module.

Bernd Scheurer

good ideas. thanks!

colB

You need to send new values out of core in to primary to a snap value module, or a snap value array, and wire that back to the input. Set the snap module so that 'thru events' are off.

This is a commonly used 'pattern' for core in my experience. It can get tricky to debug on occasion due to the boundary between primary and core complicating the init rules, but usually just works!

I have lots of Blocks and instruments that look a bit like this:

or this:

That first one for example is a clock divider, which has a gate mode, so it times the input clock... which means that it takes a couple of ticks to know how long to make the gate... so I save the gate in a Primary level Snap Value module, then it loads in on recall and all is well (assuming the timing will be the same as when the snapshot was stored...) seems to work a treat.

Second one is a monster, basically a huge system in a giant core cell, with a large data structure that gets stored in the snap value array. It seems to work ok, although there can be problems when editing. In that case, the resets behave a bit differently, so you can end up with incoherent data if the data structures is non-trivial... Best not to create patches or snapshots that matter while still in the regular dev process... That won't be a problem if you are only storing multiple individual values though...

Anyway, it's simple enough just make sure to turn off the 'Write Thru' parameter on the snap value module.

Bernd Scheurer

hi colB,

thanks for your quick response. i understand the idea behind and it's brilliant.

my actual project is a big construction-zone with daily new ideas :-) and looks a bit messy (see detail). so i made a copy auf the counter an testet ist alone. it works perfekt! thank you very much!

colB

Great. One thing to watch out for is make sure you have a dup filter on the outgoing values so you only send new values - sending data to primary, and storing it is not the most cpu efficient, so it would be silly to keep sending the same value!

Also watch out for the range setting on the snap value, make sure the range is set so that data you are using won't get clipped or ignored!

Bernd Scheurer

good ideas. thanks!