[CM] Fastest way to copy scheme variables into a shared buffer?

[Iain Duncan]

thanks for the answers, it sounds like I did a poor job of explaining what
I'm trying to do, ha. Let's try again!

There are two Max external instances, each with a complete s7 interpreter.
One only runs in the high thread and one in the low. In the high thread
there are sequencers, which have their sequence data stored in vectors of
vectors of numbers, and meta data in hashtables (though this could be
switched to vectors too). I want a UI object in the low thread that has a
shadow copy of the sequence data and is used to make a programmable
display. Nothing it does will ever lead to a change in the main data
vectors. I would like to periodically (say every 100 to 500ms) update the
shadow copy - it's ok if it takes a moment for the UI to update after a
sequence changing operation. All of this can be done at the C level if need
be. As in, I can have FFI functions that copy from the players vectors into
some other buffer, and have the low side read from this other buffer. The
shape of the data does not need to be changeable once it's going. So really
I just want the low thread to be able to read the blocks of numbers that
are in the vectors of vectors, they don't need to manipulate or be aware of
the identity of the s7 objects, just their contents.

Hopefully that is a better explanation, I probably don't know the right
terminology to use here!

thanks
iain

On Sat, Jan 22, 2022 at 6:23 AM Elijah Stone <elronnd at elronnd.net> wrote:

> > Yes, but I don't see the need.  If the s7_cell space is made available
> > to the user, I lose any flexibility in using that space later
>
> I was imagining: #define S7_C_OBJECT_VALUE_SIZE, user either ensures their
> junk fits in that or indirects.  Well, Hyrum's law applies, and I guess it
> is a little fragile, but certainly doable.
>
>
> > Why can't you use a C struct or array, or an s7 vector or list as the
> > value, and store any number of things through the value field?
>
> I am irrationally fearful of allocations, pay me no mind :)
>
>   -E
> _______________________________________________
> Cmdist mailing list
> Cmdist at ccrma.stanford.edu
> https://cm-mail.stanford.edu/mailman/listinfo/cmdist
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cm-mail.stanford.edu/pipermail/cmdist/attachments/20220122/54d52bf1/attachment.html>