Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

preparing for a 0.4.6 release: #251

Closed
7 tasks
sezero opened this issue Apr 3, 2024 · 11 comments
Closed
7 tasks

preparing for a 0.4.6 release: #251

sezero opened this issue Apr 3, 2024 · 11 comments

Comments

@sezero
Copy link
Contributor

sezero commented Apr 3, 2024

Now that the player changes are in, we can do a 0.4.6 release. There are
still tickets in the 0.4.6 milestone (which have been carried over from
previous releases whenever we've made a new one): They aren't regressions
but they have been there for a long time, so if anyone wants to attend to
them be my guest. After 0.4.6 gets out, they will be moved to the 0.4.7
milestone. And then there is #181, which I hope that @psi29a gets to some
day :) And, if there are any other issues that isn't in a milestone by a
chance and need attention, mention here and attend to it please.

In the meantime, please check / validate that the changes in this release
cycle haven't caused any regressions. Namely:

  • Test that playback, along with the player UI features, behave the same as before.
  • Test that player command line switches work the same as before.
  • Test that newly added command line switches work correctly. E.g.: -P | --playback
  • Test that newly added output backends work correctly. Namely coreaudio for mac, sndio for openbsd, and netbsd for netbsd.
  • Test that wav output haven't got any regressions
  • Test that saving to midi haven't got any regressions
  • Test that cmake'ry haven't got any regressions.

Anything else??

There possibly won't be a new release (at lest not by me) for a long time
after this, so please attend to the checklist.

I guess a due date of Apr. 10 is suitable?

CC: @psi29a, @winterheart

@raziel-
Copy link
Contributor

raziel- commented Apr 3, 2024

AmigaOS4 works fine with all but the cmake question...i cant test it (using the Makefile here) since native cmake is broken

i do get an unfreed signals error on sudden quit...I.e. using a command line option wrong, like "-r 250".

ill get the warning that the value is off and then
wildmidi returned with unfreed signals 80000008

something doesnt get closed correctly in such case it seems

@sezero
Copy link
Contributor Author

sezero commented Apr 3, 2024

AmigaOS4 works fine with all but the cmake question...i cant test it (using the Makefile here) since native cmake is broken

i do get an unfreed signals error on sudden quit...I.e. using a command line option wrong, like "-r 250".

ill get the warning that the value is off and then wildmidi returned with unfreed signals 80000008

Thanks!

Looks like we initialize audio backend before initializing thi library,
but we don't uninitialize the audio backend if library init ever fails.

I will apply the following patch to fix it, if there are no objections:

Do proper audio backend clean-up if library init or buffer alloc fails.

(Also call amiga_sysinit() before the other two in amiga builds)

diff --git a/src/player/wildmidi.c b/src/player/wildmidi.c
index 26fe1bf..21371a3 100644
--- a/src/player/wildmidi.c
+++ b/src/player/wildmidi.c
@@ -535,44 +535,47 @@ int main(int argc, char **argv) {
 
     if (!config_file[0]) {
         strncpy(config_file, WILDMIDI_CFG, sizeof(config_file));
         config_file[sizeof(config_file) - 1] = 0;
     }
 
+#ifdef WILDMIDI_AMIGA
+    amiga_sysinit();
+#endif
+
     printf("Initializing Sound System (%s)\n", available_outputs[playback_id]->name);
 
     if (available_outputs[playback_id]->open_out(output, &rate) == -1) {
         return (1);
     }
 
     libraryver = WildMidi_GetVersion();
     printf("Initializing libWildMidi %ld.%ld.%ld\n\n",
                         (libraryver>>16) & 255,
                         (libraryver>> 8) & 255,
                         (libraryver    ) & 255);
     if (WildMidi_Init(config_file, rate, mixer_options) == -1) {
+        available_outputs[playback_id]->close_out();
         fprintf(stderr, "%s\r\n", WildMidi_GetError());
         WildMidi_ClearError();
         return (1);
     }
 
-    printf(" +  Volume up        e  Better resampling    n  Next Midi\n");
-    printf(" -  Volume down      l  Log volume           q  Quit\n");
-    printf(" ,  1sec Seek Back   r  Reverb               .  1sec Seek Forward\n");
-    printf(" m  save as midi     p  Pause On/Off\n\n");
-
     output_buffer = malloc(16384);
     if (output_buffer == NULL) {
         fprintf(stderr, "Not enough memory, exiting\n");
+        available_outputs[playback_id]->close_out();
         WildMidi_Shutdown();
         return (1);
     }
 
-#ifdef WILDMIDI_AMIGA
-    amiga_sysinit();
-#endif
+    printf(" +  Volume up        e  Better resampling    n  Next Midi\n");
+    printf(" -  Volume down      l  Log volume           q  Quit\n");
+    printf(" ,  1sec Seek Back   r  Reverb               .  1sec Seek Forward\n");
+    printf(" m  save as midi     p  Pause On/Off\n\n");
+
     wm_inittty();
 
     WildMidi_MasterVolume(master_volume);
 
     while (optind < argc || test_midi) {
         WildMidi_ClearError();

@sezero
Copy link
Contributor Author

sezero commented Apr 3, 2024

Looks like we initialize audio backend before initializing thi library, but we don't uninitialize the audio backend if library init ever fails.

I will apply the following patch to fix it, if there are no objections:

Patch applied as 20a8ba2 -- thank @raziel- !

@sezero
Copy link
Contributor Author

sezero commented Apr 10, 2024

These are my binaries built from current git master (commit 18770ed)

Last call before release: Please test if you can. @psi29a : OK?

wildmidi-0.4.6-win32.zip

wildmidi-0.4.6-win64.zip

wildmidi-0.4.6-macosx.tar.gz

wildmidi-0.4.6-os2.zip

wildmidi-0.4.6-dos.zip

@sezero
Copy link
Contributor Author

sezero commented Apr 11, 2024

wildmidi-0.4.6 tagged and released: https://github.com/Mindwerks/wildmidi/releases/tag/wildmidi-0.4.6

@sezero sezero closed this as completed Apr 11, 2024
@psi29a
Copy link
Member

psi29a commented Apr 11, 2024

Woohoo

@sezero
Copy link
Contributor Author

sezero commented Apr 15, 2024

@raziel- : Assuming http://os4depot.net/index.php?function=showfile&file=audio/play/wildmidi.lha is by you, the headers in that package are wrong: You should install only wildmidi_lib.h: all others are private to the library and are used during building libwildmidi, not when building something against libwildmidi.

@raziel-
Copy link
Contributor

raziel- commented Apr 15, 2024

fixed, thank you for the heads up

@sezero
Copy link
Contributor Author

sezero commented Apr 15, 2024

looks still the same, but perhaps mirrors aren't updated yet..

@raziel-
Copy link
Contributor

raziel- commented Apr 15, 2024

http://www.os4depot.net/index.php?function=uploads

it's in the upload queue :-)

@sezero
Copy link
Contributor Author

sezero commented Apr 15, 2024

http://www.os4depot.net/index.php?function=uploads

it's in the upload queue :-)

OK, great 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants