<div dir="ltr">Hey Iain,<div><br></div><div>I'm indeed using s7 in the audio thread (and another instance in separate thread for the GUI) but I've just used simple midi input to make some visualizations,</div><div>nothing in the area of audio generation/output so didn't have any problems (yet).</div><div>Also, didn't extensively test it with real time audio in mind, just wanted to get it working. And it'll be quite some time until I get to work with it again I'm afraid.</div><div><br></div><div>Regarding your question of turning off the GC, there's a way of doing it! I think it's the (gc) function which accepts a boolean argument (to turn on or off) or</div><div>none to just run the GC.</div><div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 23 Nov 2020 at 00:27, Iain Duncan <<a href="mailto:iainduncanlists@gmail.com">iainduncanlists@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Another thought, my use case is mostly to make sequencers and algo composition aids, not to render real time audio, so while timing is important, I'm not going to be running a lot of code in the RT thread. It will likely run once per minimum time unit, ie maybe 24 parts per quarter, or something. Is there any reason I could not just have that function (clocked from max) turn off the GC, do it's work, and then turn the GC back on to clean up at the end of every tick? is that crazy talk?<div><br></div><div>Christos, I think you are using S7 in the audio thread in your VST thing right? How are you dealing with that issue, or has it not bitten you?</div><div><br></div><div>iain</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Nov 22, 2020 at 3:21 PM Iain Duncan <<a href="mailto:iainduncanlists@gmail.com" target="_blank">iainduncanlists@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Thanks Bill, that sounds promising on the malloc front then. I'll take a look at the code. <div><br></div><div><div>What I'm imagining right now is two s4m objects, one in high priority thread and one in the low, so that the majority of stuff is done in the low and the high is only used for lightweight timing critical tasks. If this doesn't pan out, I can always do the high priority thread stuff in Max or C instead, but it would be nice to be able to use S7 if possible. I *think* I should be able to keep the stuff in the high priority thread minimal enough to keep a handle on the garbage collection side, but dealing first hand with a garbage collector is new to me. (As in, I've done some soft realtime in C, and I've done work in GC'd languages, but none of that was in situations where I cared when the GC ran). If you (or anyone else) has pointers on how to learn more about that sort of thing, or how to watch when the GC runs, I'm all ears.</div></div><div><br></div><div>thanks</div><div>iain</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Nov 22, 2020 at 3:05 PM <<a href="mailto:bil@ccrma.stanford.edu" target="_blank">bil@ccrma.stanford.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">s7 calls malloc very infrequently; it has its own<br>
malloc (mallocate and friends), calling malloc<br>
only to get large blocks that it handles after that.<br>
More likely to be a problem is garbage collection.<br>
I haven't tried to use s7 in real-time, but I<br>
would expect it to be a struggle.<br>
<br>
</blockquote></div>
</blockquote></div>
</blockquote></div>