Multi-threaded rendering option for per-channel export?

[DJLevel3]

I have no idea how possible these suggestions could be to implement, but I'm submitting them since they would make the UX much more convenient.

I like to export my audio per-channel so I can render it with corrscope, but the process takes a very long time since I mostly work with the Commander X16 and I use both the YM2151 and the VERA, which means I have to get through all 16 VERA channels to get to the YM2151.

Is it feasible to have multiple threads (perhaps with the quantity user-selectable) that each export one channel at a time to speed up one-per-channel export times on more powerful hardware? I personally have an 8-core CPU but I noticed that Furnace doesn't nearly load up the whole CPU or even one core completely. I don't know how the internals of Furnace work, but it seems like an option to add multi-threading to the export would be super useful.

[LTVA1]

I can tell you it's possible. I have tried this in my fakebit tracker fork, it was prone to crashes because I was stupid but it can certainly work. It would be harder to do in Furnace because Furnace internals are more conplex than my tracker's ones. Also keep in mind that such export would use a noticeably larger amount of RAM.

[DJLevel3]

The RAM usage isn't bad for Furnace, it only uses 130mb while exporting my longest and most complex song ever.

…

On Tue, Dec 5, 2023 at 6:48 AM LTVA1 ***@***.***> wrote: I can tell you it's possible. I have tried this in my fakebit tracker fork, it was prone to crashes because I was stupid but it can certainly work. It would be harder to do in Furnace because Furnace internals are more conplex than my tracker's ones. Also keep in mind that such export would use a noticeably larger amount of RAM. — Reply to this email directly, view it on GitHub <#1396 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ALOG5ZH6QFNVRPCQKMDFXI3YH4Q3XAVCNFSM6AAAAAA3YQ2W5KVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM3TONRUHA2DC> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[LTVA1]

I mean, it's more of a concern for low grade PC. Btw convert deadlock.xm to mod, and open it in Furnace. For me it was using like 500 MiB.

[gtr3qq]

Also composing for X16 with Furnace. (yay?)
Can confirm the wait time is longer than dial up.

I've brought this up in furnace discord some decade ago, didn't think that you've made this discussion also, and there's some interesting response I should brought you up to speed.

The quick one is, it's most likey not going to ever happen.

Longer version,

I've asked the possibility of multi-thread rendering as well as skipping the empty ones.
#1576
Here's a discussion made at that time.

And Devs told me that it would be a nightmare to sync up the channels during rendering, tho to this day I'm still not fully grasp what's the need to sync them. that it would need lot of changes, and potentially even impossible with current core, for only the few special edge cases.

Considering all, it might be even better to grab a biscuit, drink some tea and let it roll, as you would in dial-up days.
Maybe deep-dive into discussions just to wait for it done.(oof)

I kinda agree with the devs, hence this comment.

You should also know, that if you only use the output for say sound analysis, stereo/mono compatibility checking, like I am this very moment, you can change the render core to YMFM which would shorten the render time considerably.
VERA PSG rendering only takes a fraction of the time than with Nuke-OPM.