Replies: 6 comments 6 replies
-
|
Another option would be to take the tracker based system out of the "music stream" API and give it a separate Sequencer API that was more suited for it. |
Beta Was this translation helpful? Give feedback.
-
|
Hi @JeffM2501! I agree the modules API is quite limited and it could be improved (as many parts of About the proposed changes, I think all of them can be directly implemented inside Also note that |
Beta Was this translation helpful? Give feedback.
-
|
Yes I think all the fixes can be made in raudio alone. I've done most of them in a local code, but I am not 100% sure they match the desired direction for raylib (hence discussion😁 ). I mostly wanted to open the discussion to talk about two things.
|
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
@JeffM2501 I agree basically, I would like real time access to instrument / channel sample data (think oscilloscopes) I did manage peek at instrument and channel triggering but that's as far as it goes with jar_xm it allocates and deallocates memory every time its gets a request for sound data I can't help but think static buffers would be better (thoughts?) between copies in jar_xm then mini audio then raylib itself the actual sound buffer must be being copied getting on for half a dozen times!!! poor bytes - well floats actually! this could be improved! I was struggling with a very intermittent almost pseudo random seg fault, thought I saw the issue and to be honest made a right hash of it suggesting a change that actually made it worse, thankfully Ray is a forgiving soul (I've not had a great few days) anyhow by chance I'm trying out the nouveau video driver and for some reason that show it up now as a definite misalignment when running with instrumentation (not just a seg fault), I'm having a break for a few days but at least I know which struct is getting misaligned (and it only seems to be allocated in one spot....) I can give you more details and instructions if you're inclined but I'm wondering if its worth the bother... so anyhow there are issues with jar_x, and as far as I can tell it doesn't look like its being maintained. at some point my personal opinion it needs replacing with something where we can get FULL access (to the data we want) and that doesn't need fixing and maintaining... there's this https://github.com/8bitbubsy/ft2play https://github.com/8bitbubsy/ft2play/blob/main/audiodrivers/how_to_write_drivers.txt but it "only"? handles mod and xm (is that enough sm3???) I also haven't checked out if we could add a moving average of what happening to the channel / instrument sound data each update / video frame and I'd need to check if that would be enough for an oscilloscope type effect or very basic signal processing for visuals It would need a through thrashing with the mod archive before creating a raylib / miniaudio driver. Oh incidently just to get the tiggering info out of jar_xm I had to play fast and loose with a hacked header with just the internal structs, right enough I'm not modifying them, but it still doesn't sit well, I certainly won't be releasing the source for fear of causing utter confusion and mayhem with the more novice coders, I do enough of that as it is! (seemingly at the moment) so even if it wasn't going to be suitable to contribute to raylib I was going to put something together to better fill the role than jar_xm, but it would be far better if something could be contributed to raylib that is both more robust and flexible, with a proper safe API where even a novice coder can request almost anything they could want to know about the mod that was playing. Have I sparked any ideas? any thoughts? I think if we can thrash something out before any actual coding takes place it will be of immense value. |
Beta Was this translation helpful? Give feedback.
-
I do not think this should be in the scope of Raylib itself. Raylib is not a music tracker system. Any application that wants to get any deeper that a surface level (more than play, stop, start over) into trackers should use a tracker library directly. Raylib should not become an image editor, sound editor, or tracker system. The very fact that Raylib can even play module files is a bonus. Part of me wonders if tracker support should be removed from Raylib core entirely and turned into an optional library (like raygui), so that it can be made optimal for trackers and maintained independently. Including more features in the core API runs the risk of adding everything and the kitchen sink to Raylib and turning it into an unmaintainable nightmare. Already we've seen the tracker system is less maintainable than the rest of the library, adding more features is not going to make that task simpler. Ray has answered the basic questions of the discussion, clean it up, keep it simple, and try to use the total length of the module for length in the existing APIs. I think this is a reasonable set of changes to keep the system maintainable. The goal is to simply fix the issues with the current API, not to massivly extend it. The only reason I'm even suggesting adding a single new API function is that it is required to replicate existing functionality that is provided by MP3/OOG streams. Music focused apps should use music libraries directly, just like a 3D physics based game would use a third party physics library. |
Beta Was this translation helpful? Give feedback.
-
|
might be an idea for any API to hold on to the request to jump or loop until the latest frame has been rendered, then set whatever property / position in the pattern/song ready for the next chunk of sound to be delivered, this would mean the tracker would have to have at least more than half a frames data "in hand" ready rendered |
Beta Was this translation helpful? Give feedback.
-
|
I have added PR #1665 to start these suggested changes. |
Beta Was this translation helpful? Give feedback.
-
|
@JeffM2501 actually thinking about it you are dead right ! Gosh the dreaded feature creep can just creep up on you... Does there exist a nice way to get "live" audio streams into raylib ? |
Beta Was this translation helpful? Give feedback.
-
|
Yes, there is the normal audio stream API. It is used internally by the music stream system. It can be used externally by any library to add audio from any stream source. |
Beta Was this translation helpful? Give feedback.
-
|
Might it not be an idea to drop mod/xm support in favour of offline rendering it to ogg Support for people wanting to know the specific of a "live" playing mod could then be provided by a third party library specifically designed to work with Raylib (which I'm probably going to do at some point anyway) btw there are at least two memory issues with jar_xm, once you get past the alignment issue (which I only actually saw reliably oddly after changing to the nouveau video driver) you're still left with the very intermittent and difficult to trace seg fault in jar_xm_next_of_sample ... |
Beta Was this translation helpful? Give feedback.
-
Can you tell me if you still experience set faults in that function or any function in jar_xm? I am also relying on it as I code in C99/C11... I can not patch in the modplug library whcih would be imho more convenient in many ways... I have to rely on tracker playback so this little player imho is a good thing for pure C. Thoughts>? |
Beta Was this translation helpful? Give feedback.
-
Currently RAudio is handling tracker files as if they were simply super compressed wave streams (like MP3 or OOG). This works for many files but does not take full advantage of other features that the tracker format supports, Things that may be desirable for game developers.
The tracker generators are setup to always loop forever. This looping is different from traditionally stream looping in that the tracker file actually has loop information in it (jump tables), and may not loop back to the start of the file, but to some other location. This means that in the current setup trackers are effectively "infinite streams" as defined by the author of the file, not just a simple start to end loop.
UpdateMusicStream tries to manually force a restart of a tracker when it detects that it has run out of samples. Because of the previous issue, this makes some trackers loop incorrectly. Some tracker files will change to a different track when one has ended, but because Update is trying to brute force the loop, the song is not played correctly, or is only partially played.
You can set the loop flag on the music structure for a tracker stream, but you can not tell the tracker sample generator to change the loop count. This again means that looping is handled incorrectly. jar_xm_set_max_loop_count is set to 0 forever, regardless of the loop flag's state.
To combat this, I suggest that a few small changes be made to how RAudio handles tracker streams.
Add a SetMusicLooping(bool loop) function to the raylib audio API. For sample based streams, this would set the looping field on the music structure, but for tracker based streams this would call the appropriate function in the tracker library (such as jar_xm_set_max_loop_count) to have the generator handle the looping.
Make UpdateMusicStream check the jar xm/mod functions to know if a tracker is done or not instead of manually counting samples. This would allow looped tracker files to loop at the module level and perform correctly.
Change the time/position interrogation functions to call the jar xm/mod position functions instead of checking the manual sample count to know where a tracker play cursor is and what the elapsed time is. This will make those functions work as best as possible for these cases. Note that in some cases it may not be possible to get a total runtime for a tracker file, because jump tables in the tracker will make it run forever. In these cases raylib should return some identifier for infinite time.
Thoughts, Questions, Concerns?
Beta Was this translation helpful? Give feedback.
All reactions