More granular control of music loops and using tracker files

Questions about the LÖVE API, installing LÖVE and other support related questions go here.
Forum rules
Before you make a thread asking for help, read this.
manadream
Prole
Posts: 9
Joined: Sun Sep 15, 2019 6:04 pm

Re: More granular control of music loops and using tracker files

Post by manadream »

Alright, so I was able to make some modifications to my code based on people's replies (like putting it all on a separate thread and whatnot) and I met all my requirements for looping and music control in general. The last bit that solved it was knowing that decoder:seek() takes seconds not samples, so I just took my sample-based points and divided them by the sample rate, and that works perfectly. Thanks for all the help. The only remaining problem I have is the xm files not having their loop points respected. For now I just have exported my xm song into a wav file and loop it using the QueueableSource logic I've got. That works perfectly fine, so I'm not in any rush to have that fixed. Thanks again for all the help, this was a nagging issue I was putting off solving until now.
User avatar
zorg
Party member
Posts: 3436
Joined: Thu Dec 13, 2012 2:55 pm
Location: Absurdistan, Hungary
Contact:

Re: More granular control of music loops and using tracker files

Post by zorg »

manadream wrote: Fri Oct 11, 2019 7:38 pm Alright, so I was able to make some modifications to my code based on people's replies (like putting it all on a separate thread and whatnot) and I met all my requirements for looping and music control in general. The last bit that solved it was knowing that decoder:seek() takes seconds not samples, so I just took my sample-based points and divided them by the sample rate, and that works perfectly. Thanks for all the help. The only remaining problem I have is the xm files not having their loop points respected. For now I just have exported my xm song into a wav file and loop it using the QueueableSource logic I've got. That works perfectly fine, so I'm not in any rush to have that fixed. Thanks again for all the help, this was a nagging issue I was putting off solving until now.
Do note that that issue will technically never be fixed, due to the fact that libmodplug has not been maintained for more than 10 years and no one is going to pick it up again for a multitude of reasons.

libopenmpt would be an alternative, but it does introduce two "regressions" compared to the featureset of libmodplug that löve uses that might be one of the reasons why the change hasn't happened yet (it does offer a compatibility layer though, so there wouldn't be too much code to rewrite for the time being): It no longer supports abc and midi files (not that those ever worked how it should have). If that switch will be made, then xm restart position will be respected, since that lib is actively maintained.

Also, as a sidenote, you could just put a position jump and a row break command on the same row on the very last order you have, that jumps to a specific position where you'd want it to restart... that will work since actual looping and control flow is not borked, as far as i know, only the restart position constant detection. (Even a pos-jump would be enough, since you can't actually specify the row to start on with the restart position, it's always the first/zeroth row...)
Me and my stuff :3True Neutral Aspirant. Why, yes, i do indeed enjoy sarcastically correcting others when they make the most blatant of spelling mistakes. No bullying or trolling the innocent tho.
Post Reply

Who is online

Users browsing this forum: Google [Bot] and 48 guests