This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

31

PC Players / playmod - UNIX-filter-type player for Linux

« on: July 22, 2015, 06:29:13 »

The program called playmod which takes a file from stdin and writes raw audio data to stdout, using libmodplug (OpenMPT would be better but I don't see that in the package manager). All exposed functions of libmodplug can be used (except for the experimental exporting features).

Download (source codes and man page): http://zzo38computer.org/prog/playmod.zip

Please write on here in case you have any question/answer/comment/complaint.

Remember: Make every program a filter!

(PS: Although it says "PC (Windows, Linux)", Linux can run not only on a PC but also on computers other than a PC as well; however I have not tested this program on non-PC computers, nor on non-Linux UNIX systems.)

List of some features:
* Listen to music
* Set how many times to repeat (including infinite)
* Seek to position; a few different ways of doing so are supported
* Export patterns in text or binary format
* View song message, sample names, instrument names, song title
* View some numeric data related to song
* Mono or stereo output
* Solo channel mode
* Solo instrument mode
* Many file formats are supported
* Input can come from any file/pipe (e.g. amigamml, curl)
* Output can go to any file/pipe (e.g. aplay, sox, nc)
* Internal global effects (optional): oversampling, noise reduction, reverb, bass boost, surround

32

Project / Coder's Corner / XM optimization and playback

« on: May 26, 2015, 09:56:31 »

I now try to write program that can optimize XM file and another program that can render XM file, both as filter-type command-line programs. (I have partially written xmopt already, but hardly any part of xmrender so far)

For rendering, I did look at LibXM codes (although mine would be a standalone program instead), so it might help, but that might not be perfect either; I can look at other codes too (such as OpenMPT), and documentations, and replies on here.

For optimizations I have many idea such as to figure out how much of each sample is actually played (and truncate the samples if they are too long, or if it ends with silence), and to trace the rows that are executed to do some other optimizations too, so it would unroll and then reroll loops. Duplicate samples and duplicate instruments can also be put together. Default volumes can be set up. Unused channels can be deleted. There are others. I don't quite know perfectly though; replies on here might help a bit too.

I mean you can pipe like this (although you could use it with any XM file; it doesn't have to be one made with AmigaMML):

Code: [Select]

amigamml < song.mml | xmopt > song.xm

33

Tracking / Re: i cant find a way to convert midi files to xm!!! halp!!!

« on: May 24, 2015, 22:31:00 »

This has absolutely nothing to do with General MIDI. MIDI doesn't inherently have a polyphonic / monophonic behaviour, and MIDI hardware was polyphonic well before General MIDI was even standardized in the late 80s. Heck, even General MIDI has a monphonic mode if you want.

I know all that. Still, using the monophonic mode of General MIDI doesn't solve the problems of using MIDI in the way to convert to XM. What I am saying is that if you wanted to use MIDI (not General MIDI, but just MIDI in general (is this confusing yet???)) to write music and then convert to XM, you would use one that is monophonic per channel (as well as a lot of other stuff, much of which is not compatible with General MIDI at all). (Such a kind of MIDI can also be used to convert XM to MIDI too, such as if you want to play it through a sequencer rather than directly. However, the main thing I was thinking is to use a sequencer and then record to a MIDI file and convert to XM. Some people prefer writing music "live", and this can be one way to do such a thing through a MIDI sequencer.)

This is device-specific and not General MIDI.

That's what I said; i.e. it is not General MIDI. (But it can be software-specific too, if you use software or hardware it doesn't make this a difference.)

34

Tracking / Re: i cant find a way to convert midi files to xm!!! halp!!!

« on: May 24, 2015, 03:39:26 »

But, General MIDI is the polyphonic kind of MIDI. If you used the monotonic kind of MIDI then the channel allocation is work OK. Instrument/samples can be loaded by defining system exclusive messages to upload it with. The controls can be define as the one supported in the command column of XM format so that it is the compatible way. Timing is still the problem, unless you calculate all of the timings and figure out what speed/tempo is needed or if you specify the timing as part of the conversion or if you use the MIDI frame timing commands.

Such thing is probably not very useful in most cases, but might be useful if you want to use a external MIDI device (it could be like a organ with multiple manuals for different group of channels) to enter the music and controls and then you can add the instruments afterward with another MIDI editor, and then use a conversion program. Nevertheless, it doesn't quite make it impossible.

None of this implies that OpenMPT needs to be changed or that such files need to be put into this MOD archive; my answering is the independent question. (Nor does it necessarily do what 8bitcomputerkid wants, but, they didn't quite specify.)

35

Tracking / Re: i cant find a way to convert midi files to xm!!! halp!!!

« on: May 23, 2015, 19:22:57 »

Unless you write the MIDI file in the way specifically to convert to XM, it won't be very good. This won't be General MIDI, therefore whatever software/hardware used to create such a MIDI file need to add whatever special commands into the MIDI file to use for XM operation (effect column commands, instruments, samples, etc). OpenMPT assumes the input is General MIDI (and has some other problems with MIDI import too), so this won't do.

36

Tracking / Re: What's your tracker / format of choice? And why?

« on: July 12, 2014, 19:16:25 »

It only really makes sense for streamed formats (such as MP3), but for modules, which were never meant to be streamed, and which technically cannot be streamed because you always need to have the whole file, it really doesn't make much sense to have this as a "feature" of the format.

While it is true, it does mean that if used as a piped input into a program, that you would need to load the entire file into RAM first before parsing it (and growing the memory dynamically if you do not know the file size ahead of time), or else to extremely complicated things to work-around it. When doing piped output it is a bit less difficult but is still difficult to do. I like the UNIX way of programs operating as filters, using stdin/stdout to transfer data instead of filenames.

True, but then again, who prints out a 150-page thick manual these days? Think of the trees!
The manual is not even written in a way that is easily readable on paper (e.g. no cross references to other pages to allow easy navigation).

Although then why are you using PDF? However like you said this has been corrected by now, but still. (I myself prefer DVI for printout anyways, but still PDF is not that good for non-printout things too; these treeview features and stuff are best for files that can be both printed and viewed on screen.)

37

Tracking / Re: What's your tracker / format of choice? And why?

« on: July 12, 2014, 03:43:02 »

None of that is practically supported by any tool out there, though. Besides, I'm not sure if this sample re-use thing can be guaranteed to work with each and every tracker/player - I do remember that DUMB has (had?) this concept of only ever reading files sequentially and never jumping backwards, which could pose a problem with such samples of course. I have no idea if this limitation still holds, though.

There is an advantage to that, but files with pointers are difficult to read/write in such a way.

It does have a TOC which can be viewed by any proper PDF viewer (usually in a treeview next to the page display). But that doesn't really matter since the latest versions use a CHM file for the manual instead of a PDF.

O, OK I didn't know that. (I got an error when I tried to upgrade it.) However, the tree view isn't for printout.

"Even"?! Are you aware that no tracker out there has this feature, and that you are pretty much the only person that ever came up with it?
But please, go ahead, take any tracker, add an SQL interface to it and demonstrate how much easier it is to edit modules by writing SQL statements rather than by typing in notes and using a GUI.

I meant one that does both, and MML too, so three things.

And I do think what program and formats you use as a user can matter for development too if you are writing programs to deal with the music or to input/output it. Some of it has only to do with the format and not the program. Some things may be specific to the program, although editing the file directly can mean that some effects have to be coded manually, if you are using them at all. There are some shortcuts you can use for chords and so on, but that makes it difficult to manually do envelopes and tuning and so on if the format doesn't have such things, even though it is possible to make such a music in such a format anyways.

38

Tracking / Re: What's your tracker / format of choice? And why?

« on: July 11, 2014, 17:56:04 »

Whether a format uses pointers or not should be of no interested for any "which format do you [as a user] like better?" discussion.

Well, it seems important to me. For doing non-12-TET tuning, and for pipe access, these can be important.

If you want to reduce the file sizes, one other thing that could be done is probably a program could be written to reconstruct all of the patterns to organize all rows making the file smaller.

S3M does support one feature that other programs don't, which is FM instruments. However, only a few programs support such thing even.

And about OpenMPT, well I use that to play music files, although, it doesn't even have SQL. And the PDF lacks a table of contents page.

39

Tracking / Re: What's your tracker / format of choice? And why?

« on: July 11, 2014, 03:24:31 »

Sounds interesting, but sadly, Milkytracker doesn't export IT files.

With those things being said, are IT files significantly larger than XM files? Or does those shortcuts make them smaller?

I don't know the compared sizes of the file types much, but I do know that, these pointers will normally increase the file size slightly (I don't know that any existing programs can take advantage of these shortcuts), although probably by less than one kilobyte.

(AmigaMML (the program I use) doesn't export IT files either, mainly because it is more difficult to use with pipes.)

IT format does certainly have some more features which are not supported in XM, such as pitch and filter envelopes and more channels. (However, note that many IT effects, such as pitch/pan, random volume variation, and more, can be simulated in XM format.)

I am one who does not use VST and does not like VST. (I can use Csound if I want to create all sort of special effects; that is much better than VST, and is free/open-source, too.)

40

Tracking / Re: What's your tracker / format of choice? And why?

« on: July 11, 2014, 00:01:01 »

Hmm, true, but I don't know much about IT files. That's why I mainly use XMs.

The .IT format uses pointers into instruments/samples/patterns/sample-data (unlike .XM), which has both advantages and disadvantages. One advantage is that you could have multiple samples with the same pointer into sample-data but different sample rates, allowing you to make tunings other than 12-TET without needing a copy of the sample data for each one. One disadvantage of this is that it is more difficult to use with pipes (a program reading from stdin and/or writing to stdout).