v1.05 release candidate (betatest)

[coderofsalvation]

HELP wanted: I'd like to kindly ask anyone to test the current v1.05 branch (here be dragons).

Various exciting reviewed PR's have been merged into the rc/1.05 branch:

builds

• ubuntu/appimage: coming soon (please build yourself or ask for it via comments to this issue)
• win64 build
• win32 build
• nix
• MAC: see below

MAC devs: As I don't have a mac, I would be SO THANKFUL if somebody could build rc/1.05 and give it a go?
@johngirvin @ghost @krehel @wormyrocks

TESTCASES

please help test the following for the next release:

1. does the new build work well with the existing milkytracker config file (in user configuration/home dir).
2. if not, does it work when temporarely moving the milkytracker config file to another file (a new one will be created).
3. does ticking classic UX-checkbox and unticking flat button (see config>layout) revert to the classic (cluttered) UI (after restarting?)
4. does the SYNTH work (sampler section)
5. does the SYNTH rename the current sample to an ASCIISYNTH string?
6. does the synth allow painting over the current wave (additional synthesis)
7. do the new effects work (sampler section and limiter in global section)
8. does the sampler section gets updated with the current sampler when selecting a different instrument note in the pattern editor (instr. backtrace needs to be enabled in global settings)
9. are the dialogs now styled with the same background colors as the palette (used to be statically defined to light-gray)
10. other thoughts?

After fixing the last bugs of rc/1.05 we can: safely merge to master, and do a release v1.05 !
Sorry for the long wait, but this workflow is a safer way, as many reviewed PR's were interdependent.

The PR's (#291) and (#282) will probably be pushed towards v1.06 as they might get refactored to lua (which ties in with more recent discussions here)

[johngirvin]

Line 94 of TrackerStartUp.cpp needs to be getenv("NO_SCALE") instead of std::getenv("NO_SCALE") to build on my macOS 12 box. It starts OK and plays a mod but I'm not really able to test it further.

[Deltafire]

Line 94 of TrackerStartUp.cpp needs to be getenv("NO_SCALE") instead of std::getenv("NO_SCALE") to build on my macOS 12 box. It starts OK and plays a mod but I'm not really able to test it further.

AppVeyor reported this problem with Visual Studio 2017 also:

https://ci.appveyor.com/project/Deltafire/milkytracker/builds/49486977

[Deltafire]

MacOS test build:
milkytracker-1.05.RC-Darwin.dmg.zip
(scroll the finder window to the right to show the MilkyTracker icon)

Some intial thoughts, testing on MacOS:

• Wow, the interface has changed! Not sure how I would now do the things that the buttons are now missing for. I found the 'Classic UX' button in settings.
• Not sure about the yellow buttons and pink numbers.
• "welcome 2 Milkytracker", I think "Welcome to MilkyTracker" would look better.
• CTRL seems to be CMD instead, but CMD-h and CMD-space are intercepted by the OS for other functions.
• The record ❤️ button seems to be stuck down.
• Opening a file asks if I want to save changes, even if there were none.

[coderofsalvation]

Line 94 of TrackerStartUp.cpp needs to be getenv("NO_SCALE") instead of std::getenv("NO_SCALE") to build on my

@Deltafire @johngirvin is fixed now in rc/1.05

* Wow, the interface has changed! Not sure how I would now do the things that the buttons are now missing for. I found the 'Classic UX' button in settings.

All non-critical buttons are moved to the context-menu (rightclick in pattern editor)

* Not sure about the yellow buttons and pink numbers.

I think these are your old milkytracker config values leaking into the new default ones.

* "welcome 2 Milkytracker", I think "Welcome to MilkyTracker" would look better.

OK will change if this fits characterwise.

* CTRL seems to be CMD instead, but CMD-h and CMD-space are intercepted by the OS for other functions.
* The record ❤️ button seems to be stuck down.
* Opening a file asks if I want to save changes, even if there were none.

will investigate thx!

btw. @Deltafire thank you VERY much for testing, really appreciate it.

[Deltafire]

Regarding CMD, I think the solution would be to allow both modifiers - I'll have a look later to see if this can be done.

Implemented in d3259da

The MacOS build is a bit broken at the moment, due to a Python2 dependency in the Docerator program it's using to generate doc icons. I think I'll remove this since Docerator has been unmaintained for 10 years now.

Docerator removed in fd29dae

[herrglocke]

Really cool to see the progress being made here, and the first steps of a GUI overhaul, which I think Milky could really benefit from. I am happy to help testing on Mac if needed, Deltafire's build seems to work OK so far. The testcases all look OK to me though the synth still has some wonky UI handling or maybe I am not using it right (e.g. when changing the paint type, the UI window is redrawn empty and only comes back after clicking one more time)

Cant wait to see more happening here!

[MetalMaxMX]

Trying out different resolutions to check how the screen looks and something looked a bit off to me. On the new UI, anything lower than 1024*768 will look off, more specifically, it won't apply any form of bilineal filtering over the UI. I checked the tickbox to make it look back to the old UI and then another regression happened, the same resolution seen from two MilkyTrackers will show off that difference in the lack of filtering. I am wondering if this is a config issue or something else.

[coderofsalvation]

@MetalMaxMX I'm thinking two things:

1. does this also happend with a fresh milktracker config? (testcase 2)
2. Perhaps this is because of: 4ea3dd0

Btw. which platform, and are you on a high-dpi or non-highdpi screen?
The idea behind 2 to do scaling similar to schismtracker.
People had been complaining about the blurryness of milkytracker when scaling up the window.

[krehel]

Test build from me - this is a Universal app supporting Apple Silicon and Intel.
milkytracker-1.04.00-Darwin-universal.dmg.zip

[MetalMaxMX]

@MetalMaxMX I'm thinking two things:

1. does this also happend with a fresh milktracker config? (testcase 2)

2. Perhaps this is because of: [4ea3dd0](https://github.com/milkytracker/MilkyTracker/commit/4ea3dd0cdc9a38138acc174ec8ed86cd27b12e1d)

Btw. which platform, and are you on a high-dpi or non-highdpi screen? The idea behind 2 to do scaling similar to schismtracker. People had been complaining about the blurryness of milkytracker when scaling up the window.

Hello! I am using Linux, Debian 11 more specifically and I built the source code myself. I am under X.org using Xfce with compositing disabled. And I am on a non-highdpi screen, the config 1.05 is using seems to be the same as the one that 1.04 already uses.

I tried with a new fresh configuration and I didn't have the issue! I then tried a 720*480 resolution with 1x scale and the UI looked a bit jagged, just like when I was trying it. Seems like it lacks some sort of bilinear filter over this mode?

[coderofsalvation]

@MetalMaxMX interesting, maybe post a screenshot?
With the settings you mentioned (and all resolutions) it looks OK here, worstcase when resizing the window it can looked jagged for certain dimensions.

I run xfce too with compositing disabled, so perhaps somehow it got resized on your side anyways?

[MetalMaxMX]

@coderofsalvation Sure, here's a few

MilkyTracker New (1.05RC)

MilkyTracker Old (1.04)

May be difficult to see but notice that bilinear filtering has been applied on MilkyTracker old (that means 1.04) while 1.05rc doesn't produce any filtering, this is with either the classic UI or not.

[Deltafire]

Maybe add a configuration option for 4ea3dd0.

[coderofsalvation]

@Deltafire good point, I'll add something like this then:

or worstcase an environment-variable (SCALING=nearest milkytracker) because the config might not be accessible yet during SDL init.

[CarstenNew]

On Manjaro Linux it compile just fine and plays all tested Mods.
I try to follow your questions:

To 1: I have to make a new config, otherwise the yellow buttons have no symbols on.
To 2: Then i did this
To 3: Yes. It worked both ways.
To 4: I need more practice to use it properly but it seems to work.
To 5: Yes. I try to rename the sample to get a other sound, but this is not possible.
To 6: Yes, i can paint over, but what i get i will not call a additional synthesis...
To 7: Yes, i can add the FX to the samples.
To 8: Yes, works fine.
To 9: Yes.
PS: The UI scaling is not better, at least for me. I have to try different obscure "custom" resolutions on my normal FHD-Laptop to get a proper result. When i chose a higher resolution from the list, the performance is unusable, like in the old Milkytracker.

[FaZz321]

Hello. I built rc/1.05 for Arch Linux and just tried to break all the things I could break. )

Sample editor/synth:

1. Strange behavior for the min and max values on synth sliders. You can have different result with the same parameter values. You can reproduce it with moving slider cursor using mouse or by clicking left-right arrows. Easy to see with "wave type" slider in add-synth (try to go 'beyond' min/max values, by using arrows and using cursor, you'll get different results).
   
   
2. Changing synth type not always redraws the synth controls. It'll be redrawn only after you move synth window a bit.
   
3. Synth window could stop producing sounds during the synth editing. If you click "ok" and close the synth edit window, the sample sound will be played, so it's not the synth settings. You can reproduce it by zapping everything with classic UI, but it's not the only way to do it (not sure what the other ways are but I did it without zapping the project).
4. Are context menu generators now additive too? It's feels like a bug (not sure). When you use fm-synth two times in a row it acts additive (sums two waves), but when you switch to add-synth it overwrites the results. Add-synth is applied to selection and could be used on other waves, fm-synth doesn't. It's a bit all over the place - very unpredictable IMO.
5. Switching synth form from 'add' to 'fm' erases the original sample even if the action is canceled in the end. You can lose a sample by mistake.

Other things:

1. Couldn't find a button for zapping everything in new UI. Not sure how can I start a new project in 1.05 without closing the milky tracker.

[coderofsalvation]

These are good points (thanks!), especially the lazy redraw stuff.
I'm a bit busy recently but hope to look at it asap.

NOTE: if you can't find something in the non-classic UI, it's in the context-menu (right-click)

[coderofsalvation]

update: I'm a bit slow as you can see (have to finish a home renovation before winter hits).
Havent' been able to debug the above (last) issue before doing the release..
If anyone wants to jump in, otherwise bit of patience please.

[coderofsalvation]

Small heads up: still swamped with (other) work sadly, but did not forget.
Another note, from the Trackers and Retro Community discord: "remove the onboarding info from the instrument list"

[coderofsalvation]

1. Strange behavior for the min and max values on synth sliders.

thanks, fixed in latest commits: it did update after clicking + or - buttons of sliders.

2. Changing synth type not always redraws the synth controls.

thanks, fixed in latest commits

Synth window could stop producing sounds during the synth editing. If you click "ok" and close the synth edit window, the sample sound will be played, so it's not the synth settings (...)

The synth will now position the cursor to a note-column (which will ensure audition, because livejam does not happen on value-columns). Not an ideal fix, but it does help.

Are context menu generators now additive too? It's feels like a bug (not sure).

I agree this was a confusing default. I've decided to make the synth non-additive by default, but if you select the sample before hitting the synth-button, it will launch the popup in additive/layer-mode (described in the docs too).

Switching synth form from 'add' to 'fm' erases the original sample even if the action is canceled in the end. You can lose a sample by mistake. (...)

On top of that (to prevent losing a sample), the synth-buttons will be disabled if there's a regular sample (not generated by the synth).

OK I'm going to compile some extra targets, then a last crowdsourced betatest and then we can release.

[coderofsalvation]

Latest builds are at the pre-release:

https://github.com/milkytracker/MilkyTracker/releases/tag/v1.05.00

[elfakyn]

Did a quick build of 1.05.01 for Mac (Apple Silicon). Let me know if there are any issues.

Will give it a proper spin later, but so far I've been able to install and run it.

milkytracker-1.05.01-Darwin.dmg.zip

[lmnoop]

Did a quick build of 1.05.01 for Mac (Apple Silicon). Let me know if there are any issues.

Doesn't seem to run on M1 macOS 13.7.1.

[coderofsalvation]

@elfakyn thanks for the effort, is it an arm64, x86_64 or x86 build?

[lmnoop]

"Apple Silicon" suggests arm64.

[coderofsalvation]

@lmnoop thanks.

Btw. various mac-building experiences have been documented in the the previous version

[elfakyn]

Thanks for the info @lmnoop . Yes, it was built for ARM64, on an Air M3 MacOS 15.1.something.

I managed to get my hands on a second machine and it doesn't run on that. I'll give it another shot now that I've got a better testing set-up. Thanks @coderofsalvation for the links.

I don't have an Apple Developer account but I hope that won't be needed...

Edit: I was able to confirm that it's a code signing issue. Running xattr -d com.apple.quarantine /Applications/Milkytracker.app fixed it. Let's see what can be done so it works without that...

[elfakyn]

See newer comment here.

I think I got a universal binary going (arm and x86_64). Here it is: Use the one in the newer comment above.

milkytracker-1.05.01-Universal.dmg.zip

I would appreciate if someone can do the steps under "Installing" below (especially someone on Intel). (cc @lmnoop would you be able to test this one?)

How I built it

(previous versions of this comment had a much more janky method)

First, install dependencies:

• homebrew
• brew install cmake
• Install XCode from the App Store (not brew install xcode). If you already have XCode via homebrew, you need to install from the App Store then sudo xcode-select -switch /Applications/Xcode.app
  • If this is your first time with xcode, run sudo xcodebuild -license followed by sudo xcodebuild -runFirstLaunch

To build, run the following commands:

git clone [email protected]:milkytracker/MilkyTracker
cd MilkyTracker

Create build_mac.sh and make it executable.

#!/bin/bash
# MacOS universal build
# https://github.com/milkytracker/MilkyTracker/issues/341#issuecomment-2517207448
cmake -E make_directory build
pushd build
cmake -DCMAKE_BUILD_TYPE=Release -DCMAKE_OSX_ARCHITECTURES="arm64;x86_64" -DCPACK_SYSTEM_NAME="Universal" ..
cmake --build . --config Release
codesign --force --deep --sign - src/tracker/MilkyTracker.app
cpack .
popd

Now ./build_mac.sh.

This will create a universal binary in the build directory, assuming all goes well.

Installing and running MilkyTracker as an end user

Download the dmg. Open it and drag MilkyTracker to Applications.

Now go to Applications and double-click MilkyTracker. You'll get this error:

Click Done, then go to System Settings -> Privacy & Security -> Scroll all the way down -> "MilkyTracker" was blocked to protect your Mac. -> Click Open Anyway

Now you have to click "Open Anyway" once again in the resulting pop-up.

You will be prompted for your password/touch id, that's normal. Enter it.

Done!

You can't get rid of these steps unless you have an Apple Developer license.

[lmnoop]

I think I got a universal binary going (arm and x86_64). Here it is:

milkytracker-1.05.01-Universal.dmg.zip

This still doesn't run on Ventura for me. But looky here. Thanks to your detailed steps, even I was able to build one myself:

milkytracker-1.05.01-Universal-Ventura.dmg.zip

[lmnoop]

New build with fixes from #347

milkytracker-1.05.01-Universal-Ventura.dmg.zip

[elfakyn]

This newest one works for me properly on Sequoia 15.1.1. I'm surprised there are backwards compatibility issues with my build. Out of curiosity, what version of XCode did you build it with?

[lmnoop]

The platform selection screen says Version 15.2 (15C500b) targeting macOS 14.2, which seems weird to me because the system itself is 13.7.1.

[boonier]

@lmnoop with your latest build above - I'm on Ventura 13.6.3 and getting what looks like an unsupported architecture, or, something like when the OS is not supported.

Maybe I'll try just building it myself?

[lmnoop]

That's the exact thing I got with @elfakyn's build but with her instructions, building my own was a breeze.

[boonier]

Actually I just updated to 13.7.1 as I didn't realise that I was behind

The app loads now! Weird that it's that specific a build though

[elfakyn]

Here's a build that "should" work on old Mac OS versions, as well as current versions.

milkytracker-1.05.01-Universal-MacOS10.6.dmg.zip

I looked into it and you can set a deployment target. I experimented and 10.6 is the earliest it compiles on (older versions give the error c++: error: -fobjc-arc is not supported on versions of OS X prior to 10.6). This also doesn't compile for 32 bit because of -fobjc-arc either, but those machines are ancient by now.

build_mac.sh

#!/usr/bin/env bash
# MacOS universal build
# https://github.com/milkytracker/MilkyTracker/issues/341#issuecomment-2527798897
cmake -E make_directory build
pushd build
cmake -DCMAKE_BUILD_TYPE=Release -DCMAKE_OSX_ARCHITECTURES="arm64;x86_64" -DCPACK_SYSTEM_NAME="Universal" -DCMAKE_OSX_DEPLOYMENT_TARGET="10.6" ..
cmake --build . --config Release
codesign --force --deep --sign - src/tracker/MilkyTracker.app
cpack .
popd

If someone can try the binary I've attached, that would be appreciated. In particular:

• Does it work on older mac versions?
• Does it still work on both arm and intel?
• Does it have any weird bugs on older mac?

If this works properly, I can open a pull request to add the build script for mac.

[coderofsalvation]

Thanks for the efforts so far ❤

btw. not sure how easy it is, but some users have asked 10.5 builds [including myself, I have an old macmini with OSX 10.5.8], so if it's as easy as changing "10.6" to "10.5" please do]

[elfakyn]

Happy to help!

Unfortunately no, there are compilation errors on 10.5 and lower because of -fobjc-arc (automatic reference counting).

~/repos/MilkyTracker/build ~/repos/MilkyTracker
-- Enabled MIDI support (Core MIDI)
LHA decompressor disabled (lhasa unavailable)
-- Enabled GZIP decompressor
ZIP decompressor disabled (zziplib unavailable)
-- Enabled Core Audio support
-- Configuring done (0.1s)
-- Generating done (0.1s)
-- Build files have been written to: /Users/elfakyn/repos/MilkyTracker/build
[  1%] Building CXX object src/midi/CMakeFiles/midi.dir/osx/MidiReceiver_CoreMIDI.mm.o
c++: error: -fobjc-arc is not supported on versions of OS X prior to 10.6
make[2]: *** [src/midi/CMakeFiles/midi.dir/osx/MidiReceiver_CoreMIDI.mm.o] Error 1
make[1]: *** [src/midi/CMakeFiles/midi.dir/all] Error 2
make: *** [all] Error 2
src/tracker/MilkyTracker.app: replacing existing signature
CPack: Create package using DragNDrop
CPack: Install projects
CPack: - Run preinstall target for: MilkyTracker
CPack Error: Problem running install command: /opt/homebrew/bin/cmake --build . --target "preinstall"
Please check /Users/elfakyn/repos/MilkyTracker/build/_CPack_Packages/Universal/DragNDrop/PreinstallOutput.log for errors
CPack Error: Error when generating package: milkytracker
~/repos/MilkyTracker

I tried disabling it (which could itself cause problems) but it's encountering other errors which are beyond my mac knowledge...

[100%] Linking CXX executable MilkyTracker.app/Contents/MacOS/MilkyTracker
ld: warning: ignoring duplicate libraries: '../ppui/osinterface/libosinterface.a'
ld: warning: support for macOS with 10.5 minimum deployment target is deprecated and will be removed in a future release
0  0x104b6fee4  __assert_rtn + 160
1  0x104b7041c  mach_o::relocatable::CFISection<arm>::addCiePersonalityFixups(mach_o::relocatable::Parser<arm>&, libunwind::CFI_Atom_Info<mach_o::relocatable::CFISection<arm>::OAS> const*) (.cold.1) + 0
2  0x104ad60ac  ld::passes::stubs::x86_64::classic::StubHelperAtom::copyRawContent(unsigned char*) const + 0
3  0x104ad38c8  ld::passes::stubs::Pass::makeStub(ld::Atom const&, bool) + 4744
4  0x104ad4b50  ld::passes::stubs::Pass::process(ld::Internal&) + 1500
5  0x104ad50ac  ld::passes::stubs::doPass(Options const&, ld::Internal&) + 100
6  0x1049a88e0  main + 664
A linker snapshot was created at:
        /tmp/AnimatedFXControl-x86_64.out-2024-12-09-131911.ld-snapshot
ld: Assertion failed: (targetAtom != NULL), function Fixup, file ld.hpp, line 1094.
c++: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [src/tracker/MilkyTracker.app/Contents/MacOS/MilkyTracker] Error 1
make[1]: *** [src/tracker/CMakeFiles/tracker.dir/all] Error 2
make: *** [all] Error 2

A 10.5 build doesn't seem immediately trivial to me, but maybe there's a quick fix from someone who knows the code.

[Deltafire]

Quick test on Linux/Wayland. Seems to work okay until I drag the window to a second screen, which causes the GUI to freeze. No error messages and the song keeps playing. Tried with the OpenGL render and also with it disabled using NO_OPENGL=1.

Also regarding usability; I expected that double clicking on a file to load it would also bring me back to the main menu, instead of having to click Exit. Seems a bit strange that it doesn't, but I can also see a benefit of it being the way it is.