milkytracker / milkytracker Goto Github PK

Original bug report:

http://modarchive.org/forums/index.php?topic=1357.0

Confirmed on Windows 64-bit.

16:18 also another annoying thing (not a bug) is that check boxes can only be activated by clicking the boxes themselves, not the text next to it (like FT2 and all common-sense GUIs)

With the SDL2 port, the shift key doesn't work when entering text into dialogs (eg. instrument names, song title), so it's not possible to type capitals.

..instead it moves Milkytracker to the top-left of the desktop, with no window decorations.

I've just noticed that switching between tabs in the Cocoa version - even when both tabs contain small or empty modules - involves a 5 second lockup and occasionally a beachball. The same switching in the SDL version is almost instantaneous. Not a showstopper, but could cause problems for anyone using Live Mode in a performance situation.

Forget that. I'm an idiot. An idiot who was testing this while running the build out of Xcode. Please close/delete/whatever!

Example:

Double-click a .mod or .xm file, Milkytracker launches because it's registered as a handler for that file type, it doesn't load in the file that was double-clicked.

After cloning, running autoreconf -i and ./configure (which runs without any warning), make step fails:

g++ -DHAVE_CONFIG_H -I. -I../.. -D__LINUX_ALSASEQ__ -D__LINUX__ -DMILKYTRACKER -D_REENTRANT -I/usr/include/SDL2 -I../../src/milkyplay -I../../src/ppui -I../../src/tracker -I../../src/ppui/osinterface -I../../src/ppui/osinterface/sdl -I../../src/ppui/osinterface/posix -I../../src/midi/rtmidi -D__FORCE_SDL_AUDIO__ -g -O2 -MT posix/MidiReceiver_pthread.o -MD -MP -MF $depbase.Tpo -c -o posix/MidiReceiver_pthread.o posix/MidiReceiver_pthread.cpp &&
mv -f $depbase.Tpo $depbase.Po
posix/MidiReceiver_pthread.cpp:34:20: fatal error: RtMidi.h: No such file or directory
#include "RtMidi.h"

Most pat files don't read correctly.

Here's an example. Playing a scale here results in some random-sounding pitches, though some of it is definitely correct there are also errors. Here's the offending .pat file:
https://drive.google.com/file/d/0B-NDUlDEAog8WjZkOVotQ1ZIeUU/view?usp=sharing

Most freepats I've tried act the same way. Often, sample names become corrupted as well. I've even had milkytracker lock up completely when reading a .pat, though I can't seem to reproduce that consistently.

22:32 <zoner> I don't know if this is a known bug or what, but if you supply a filename at the command line that's not a full path, then subsequently the song gets saved at the last place that milkytracker has changed directories (in file browser, instrument and sample chooser, etc)
22:32 <zoner> it gave me a near heart attack when it looked like a few hours of work had just vanished
22:32 <zoner> but it was instead just saved someplace deep in a directory structure where i have samples
22:33 <zoner> so now i just don't trust passing a file name on the command line at all
22:33 <eightbitbubsy> shouldn't it always save to the current working directory?
22:34 <eightbitbubsy> (I don't know how it works though :D)
22:34 <eightbitbubsy> e.g. the directory that is open in disk op.
22:35 <zoner> like, you do $ milkytracker mysong.xm
22:35 <zoner> then you go look for a new sample bongas.wav with the sample chooser thing
22:35 <zoner> and here you are changing directoies
22:36 <zoner> then when you save it'll save the file "current-directory/bongas.wav"
22:36 <zoner> errr
22:36 <zoner> sorry
22:36 <zoner> current-directory/mysong.xm
22:36 <zoner> not directory-where-mysongxm-is/mysong.xm
22:37 <zoner> because it probably just saves "mysong.xm" but now you're in the directory that your bongas are in
22:37 <zoner> whereas in all other cases, it is a full path
22:39 <zoner> solving this i think means either not changing current directory ever, or somehow making sure the command line argument is converted to its full path version of itself during argument parsing

This is a feature request for supporting the XDG Base Directory Specification.

The specification works around a bug during the early UNIX v2 rewrite which caused files prepended with a '.' to be ignored from the output of ls.
While this "bug" has become a feature for some, it has also become a headache for users when developers continue to assume HOME is a great place to dump configuration files and local caches.

To address these issues XDG Basedir was formed to give developers a standard location for these files (much like how / is well structured with /usr/share, /var and /etc) and giving the users control over where they are placed in their HOME.

If you were to support the XDG specification the following locations would change:

# XDG_CONFIG_HOME should expand to what the user set or fallback to "$HOME"/.config"
"$HOME"/.milkytracker_config → "$XDG_CONFIG_HOME"/milkytracker/config

A basic patch might look something like this; although I'm not sure what milkytracker_temp is for.
(Note: This was done long ago, I haven't invested much into milkytracker for the last year or more.)

(Edit: I noticed now that I don't correctly reset home to getenv("HOME"); if it fails to get XDG_CONFIG_HOME, oops :P)

diff --git a/src/ppui/osinterface/posix/PPSystem_POSIX.cpp b/src/ppui/osinterface/posix/PPSystem_POSIX.cpp
index 49f2869..e683779 100644
--- a/src/ppui/osinterface/posix/PPSystem_POSIX.cpp
+++ b/src/ppui/osinterface/posix/PPSystem_POSIX.cpp
@@ -59,28 +59,28 @@ const SYSCHAR* System::getTempFileName()
    // create something that "might" work out
    if (buffer == NULL)
    {
-       char *home = getenv("HOME");
+       char *home = getenv("XDG_CONFIG_HOME");
        if(home)
        {
            strcpy(buffer, home);
-           strcat(buffer, "/.milkytracker_temp");
+           strcat(buffer, "/milkytracker/temp");
        }
        else
-           strcpy(buffer, "milkytracker_temp");
+           strcpy(buffer, ".config/milkytracker/temp");
    }
    return buffer;
 }

 const SYSCHAR* System::getConfigFileName()
 {
-   char *home = getenv("HOME");
+   char *home = getenv("XDG_CONFIG_HOME");
    if(home)
    {
        strcpy(buffer, home);
-       strcat(buffer, "/.milkytracker_config");
+       strcat(buffer, "/milkytracker/config");
    }
    else
-       strcpy(buffer, "milkytracker_config");
+       strcpy(buffer, ".config/milkytracker/config");

    return buffer;
 }

Thanks o/

Please, add some protocol or web interface for fully control MilkyTracker throw console or telnet client.

It will give many futures:

• live collaboration on music creation from two or more users in different places
• using as sound mixer for games with network support
• and many other usefull tricks

To better represent available applications in a general application installer, Fedora (and possibly some other GNU/Linux distributions) would want applications to ship with a bunch of metadata [1].

Fedora recommends package maintainers to add these to applications that do not already ship them, and send the metadata to the upstream project. This way different distributions will hopefully ship mostly the same description.

The main content that is needed are:

• The one-line summary
• The two or three paragraphs of description
• Screenshot(s)

I can write the metadata xml file based on existing package metadata we have. But since this data may end up in many distributions, I would like to ask the application authors if they want some particular things in the metadata. Otherwise, I'll just figure out something according to my taste and the available guidelines.

References:
[1] http://people.freedesktop.org/~hughsient/appdata/

From #milkytracker:

--> LazyBeard ([email protected]) has joined #milkytracker
<LazyBeard> Hi. I'm too lazy to create an account on Github or on Milkytracker forum, so I'll just do a bug report here.
<@pailes> LazyBeard, no problem, go on
<LazyBeard> I managed to compile the latest version of Milkytracker 0.90.87 on Lubuntu 14.10 x86_64, and when I use it, no matter what I do, where I am in the app, or whatever, I can instantly crash it just by pushing MAJ + 2 (the key above the letters where there is the number 2)
<LazyBeard> I then get in the console : Crashed with signal 11 [...]  A backup has been saved to ~/BACKUPnn.XM \n  Segmentation fault (core dumped)
<@Deltafire> MAJ+2?
<@Deltafire> the " symbol is above the 2 for me
<LazyBeard> I must precise that I am using an AZERTY keyboard layout.
<@Deltafire> what is MAJ?
<LazyBeard> MAJ is the way french called the SHIFT key.
<LazyBeard> call* sorry
<@Deltafire> ok, so you're trying to insert the number 2?
<LazyBeard> Not necessarily. I discovered that bug by trying to enter a 2 when giving a sample size, but it turns out that I can crash the program when I push 2 at any moment

Today I created a build system for a basic project using CMake for the first time, and achieved what I needed to do in about 5 lines - really easy to set up.

Just thought I'd put this here as a suggestion for discussion - I think you even suggested it at Sundown. Not sure how much work it'd be to move from Autotools to CMake, but the automatic Xcode/VS/Makefile etc generation is absolutely brilliant.

Any thoughts?

Hello, I've done some fuzzing on Milkytracker and found a bunch of files that crash it. Since these files are potentially security relevant (since the bugs may be exploitable), what's the procedure of sharing them with you (the devs)?

From http://modarchive.org/forums/index.php?topic=2578.0

".85 still freezes on exit when running from %ProgramFiles% or similar location and milkytracker.cfg doesn't exist. It is trying to save the configuration, but can't do so because higher access rights are required. If you first run MilkyTracker from another location or as an administrator, the file will be created successfully and configuration is saved normally from then on when running with restricted access."

I suspect this issue will also affect importing song formats which cause MT to write a temporary file to disk.

I'm using the ubuntu ppa version.
When I turn on fullscreen via command line, the initial splash image is fullscreen, then upon showing the actual tracker the program quickly turns into windows mode.

19:14 <zoner> Hi, I compiled the "pending" branch (linux, amd64) and noticed that entering instrument,volume,effect column data does not work. I traced the problem back to the asciiToHex function in PatternEditorControlKeyboard.cpp
19:15 <zoner> the definition is currently static pp_int32 asciiToHex(pp_uint16 ascii)
19:15 <zoner> but i debugged this and having the ascii parameter as pp_unit16 is messing things up on my build
19:16 <zoner> if I change it to "char ascii" everything works great

If I try to set up ASIO output in the current release (v0.90.86), I can't get it to work. I get the error message:

"Sound driver initialization failed. Try different settings or driver."

However, if I build the latest code myself in Visual Studio, I don't have the same problem. I haven't changed anything in the code... so I have no idea what could be wrong in the released version downloadable on the website?

For now, I will continue to use the version I build myself.

Replace the binary config file with plain text, allowing easier configuration and enabling additional options without requiring complication of the config panels.

Something similar to:

# This is a comment
key = value

Would be a good starting point (for more complex configuration we could look at yaml or tcl).

(feature request from raina via IRC)

can we have a setting to invert the way scrolling zooms in the sample editor and instrument envelopes. and maybe actually scroll instead of zooming when a keyboard modifier is pressed

Possibly due to commit d315a47, the waveform display changes its colour to black on black when using a recent MilkyTracker git version with an existing config file from an older MilkyTracker version. I guess new colours need to be appended at the end of that enum rather than inbetween. If that is indeed the case, it may also be worth checking if increasing the number of colours will break (de)serialization of the config file in any other way, too.

The first problem with the driver is that some types are being used incorrectly for setting up the callback. Namely, the call to waveOutOpen() casts the callback function to a DWORD when this should be DWORD_PTR. On 32bit builds we may get away with this; on 64bit builds we lose precision and end up crashing. This is trivial to fix.

The second, more serious problem is that system calls are present within the callback function, which is not allowed and causes deadlocks.

From MSDN:

Applications should not call any system-defined functions from inside a callback function, except for EnterCriticalSection, LeaveCriticalSection, midiOutLongMsg, midiOutShortMsg, OutputDebugString, PostMessage, PostThreadMessage, SetEvent, timeGetSystemTime, timeGetTime, timeKillEvent, and timeSetEvent. Calling other wave functions will cause deadlock.

The driver needs refactoring to correct this, so I am investigating a fix. We should also look at more modern APIs like XAudio2, which from briefly Googling is a replacement for DirectSound.

There's no configure script. The README directs us to the INSTALL file for more details on how to build, and the INSTALL file says to use ./configure etc., except that said file doesn't exist.

The website http://milkytracker.org/ is down :/ impossible download MilkyTracker :/

There's currently only four 12x12 fonts, most of which are difficult to read for spacing and geometric reasons.

I've made a variety of fonts in the past, and I'd definitely be willing to contribute my own work to have a better selection of readable 12x12 fonts, especially if I can get help to integrate them.

An option to increase vertical spacing between rows would also be a major boost for the usability of the current fonts.

This is quite an old bug, I remember encountering it with older version of MilkyTracker.

I've tried to open one S3M file from Jazz Jackrabbit with MilkyTracker v0.90.86 on ArchLinux x86_64.

I'm not sure if I can distribute the S3M, so I'll just leave the name and md5sum here:

dbdf29b67541f89fb6e30a978f44c1c4  Fanolint.s3m

I ran MilkyTracker inside valgrind to get more information about the nature segfault.
The output of valgrind --leak-check=full --show-leak-kinds=all -v milkytracker Fanolint.s3m is available here.

Two related bugs:

16:13 I found a bug in MilkyTracker... In the instrument editor, if you select a preset (0..9) and the current point selected is above the length of the new preset, the current point marker will go nuts and place itself in a weird spot
16:14 also when you insert a point, Milky doesn't check if there's room for it inbetween, so if currX and nextX are the same, you'll get a new point that has the same x value as the previous, which is considered illegal
16:14 all points must have a padding of 1
16:16 (in x, not y)

i don’t know what do you all think about these feature suggestions:

• import/export vgm/vgz files
• support ascii-based files, besides binary files (just imagine files like .mod , .it, .s3m, etc., in their ascii version, all specs text-editable, and samples stored in hexdump or uuencode ) - for example, vortex-tracker default file is an ascii file, and sometimes we need such interoperability for gaining time and efforts on editing tunes
• supporting python/lua/etc. plugins would be great because it would help us to create/add/share such features on our own, without need to compile MilkyTracker just for testing (like me, i only installed MilkyTracker from Ubuntu/Debian repository)

I always thought of these guys as blocking 1.0 release but here goes again:

Setting E31 should quantize note frequency to semitones when doing 3xx/Mx portamento.
Here's an example module and wav renders of it from FT2 and MT.

Preamble: I'm aware of the reasons why MT supports only 32 channels out-of-the-box ("real" FT2-ish XMs supporting only that much, MT being used on low-end platforms without CPU power to mix more channels, the "don't just double the channel amounts by 2" doctrine from FT2, already having the ability to use more channels with quite simple source hacks etc.) Still, I'd like to propose adding a support for more channels (at least 64) in master branch.

My points are:
a) more than 32 channels have been and already used by many (if not most) of the other contemporary trackers & players, including, but not limited to, IT, MPT, Skale, XMPlay etc., since increasing the amount of channels in XM-stored modules to e.g. 64 doesn't really require any other code changes than upping the constants in the application, so doesn't have any real cost other than making the XM incompatible with legacy software, and can (and does) provide real benefits (see below),
b) 32 channels for modules is simply too little for format without multilayered instruments or stereo samples; it happens for me regardless of the genre, both for e.g. orchestral music & chiptunes - it takes about 4 layers for a fat synth or a fat drum - double or triple that to 8 or 12 to make it possible to use stereo effects. I hit 32 channels before I'm even able to lay out the synths. It takes about 16 channels to have a properly sounding piano emulating two hands with chords played, 6 channels to emulate a guitar etc. ... so that's a real blocker. 64 channels usually leave you with some spare place, but 32 channels often leave you with not enough space for real layering and with the need to stack couple of instruments on single channel, killing the reverb/echo/ambience possibilities,
c) MT works properly (including GUI) recompiled with constants upped to 64/128 channels, at least on Win32 as far as the couple of weeks of testing I've done went, so there's no real effort needed here,
d) FT2 did that mostly because 32 channels with 48k sampling, effects and live playback was already pushing the hardware available at the time to the limit, and because 32 channels was an increase from FT1 and MOD format anyway; today, even an ARM smartphone has more CPU power than needed to mix 64 (or more) channels properly,
e) switching to 64/128 max could've been done with platform-dependent compilation, so that it only happens for those platforms where it's completely not an issue,
f) it could be/should be made an option (with a 1st time warning popping possibly), that XMs done in more-than-32-channels-mode are incompatible with legacy XM players/trackers,
g) I (and probably other people in similar situation to me) wouldn't have to maintain a fork and wouldn't have to port changes from master constantly just for the sake of having that particular feature.

IMO there would be no harm done, no kittens killed and no rainforests destroyed in the process. I can volunteer to do the PR with relevant changes myself, if nobody else wants to patch it together BTW.

tl;dr please give us the ability to enable 64 (or more) channels out-of-the-box, so that the community gets the most of MT, which is awesome already, but can be even more awesome by having a killer feature other trackers already have for like 10 years.

Problem:

• There's a name of the instrument is long enough to horizontal scroll bar to appear
• Edit name so it could fit the window, that will cause the scrollbar to disappear
• But if scrollbar was shifted window will remain it's shift

Temporary solution:

• In edit mode still possible to navigate to the beginning of the line so it will scroll back.

Please consider writing and installing an AppData file with the application description and some screenshots, else MilkyTracker looks really bad in the GNOME and KDE Software Centers. We'd love to showcase more applications, but without the extra data file we can't. See http://people.freedesktop.org/~hughsient/appdata/ for details; thanks!

Richard

Currently in MilkyTracker (0.90.85), when the tremolo effect is discontinued, the volume is not reset. I was unable to find what the expected behavior is in Fasttracker 2, but several other players (I unfortunately do not have access to FT2 itself) that I tried did reset the volume once the effect was discontinued. What is the correct behavior of the effect?

Additionally, there appears to be an error in the documentation for the tremolo effect. It states that "The pitch is reset when the command is discontinued." I believe this is an error, since the tremolo effect does not affect pitch.

Hi, guys!
I have some issue with file browser: cyrillic names are displayed incorrectly.
https://vk.com/doc4294202_437351090
Ubutnu 15.10 Mate, MilkyTracker 0.90.85, locale ru_RU.UTF-8.

Simply put, I'm a dvorak user, and notes are put in seemingly random places unless I switch to qwerty.

I'm using SDL2+Linux

I have a IT file, VLC and SchismTracker do play them
here an example file! chount.zip

please fix it

Talking about the little value in the main panel above Expand and Shrink buttons. When Config > Misc > Pattern Editor > Paste autoresize is enabled and you paste something that extends the pattern, this number isn't updated.

Hello
I am trying to install Milky on fedora, and as I understood I try to build the source
For that I need to create the ./configure file with something like AM_PATH_ALSA=/usr/bin/ autoconf (am I correct? it is not said in the README nor INSTALL files)
If I do so AM_PATH_ALSA=/usr/bin/ autoconf && ./configure I get this error:

./configure: line 2405: syntax error near unexpected token `dist-bzip2'
./configure: line 2405: `AM_INIT_AUTOMAKE(dist-bzip2 subdir-objects)'

Do you know where it comes from? Am I on the right track?
Thank you!

This is confirmed on Windows, but doesn't affect the SDL2 port.

The SDL version has a tick-box to enable loading unknown file extensions.

Mention that submodules are required for Windows, but not all are required for linux/osx/etc.

It looks like configure.ac was removed but the installation instructions in the root README and INSTALL files still refer to autoreconf, so it's not clear what replaced them. (I'm still trying to build, actually)

1. Create a new tune
2. Create an 8-bit sample that is roughly 16 bytes long
3. Paint a waveform on that sample
4. Save as MOD
5. Reload to find that the beginning of the sample has been corrupted

This did not happen in the previous MilkyTracker release, and I suspect it has something to do with the 2 sample fix when saving to MOD. Maybe try adding padding at the beginning instead of messing up the looped sample?

The Fedora build package uses the system installed rtmidi instead of the internal copy.

Consider removing the internal version of rtmidi and use the system version instead.

Note: The Fedora patch would have to be extended with configure checks.

So, this thing still. Clicking the MT taskbar icon repeatedly makes the window gravitate slowly towards the top left corner, and beyond!

Improvement from current behavior where new instruments are always inserted at the end. This feature would require an auto-remap of all subsequent instruments.

Also implying that the [-] button would remove the instrument at selected position.

PS. If this is also implemented for samples (for the sake of consistency), keyboard mappings would have to be changed in a similar fashion. This is not as urgent imo.

Subbi mentioned this at Sundown.