It is currently Thu Jan 17, 2019 6:45 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 35 posts ]  Go to page 1, 2, 3  Next
Author Message
PostPosted: Tue Dec 07, 2010 4:00 am 
Offline

Joined: Sat Jan 23, 2010 11:41 pm
Posts: 1161
Every time I had thoughts about a NES project, during years, I always faced the same problem. Although nowadays there are a lot of NES music tools, to my knowledge there is still no general solution to create and add music in a demo or music and sound effects in a game. I consider sound and music as very important part of any game, and I know very well how demotivating lack of ready-made solutions in this area could be - sound programming is very specific thing, not everyone able to get into, and music/sound code could be large enough project itself. I think, lack of the sound solution has some contribution in slowing down homebrew development on the platform, because everyone have to develop their own solutions, which takes a lot of time and efforts.

So I invite everyone who interested to discuss, think up, and implement such solution. Nothing too fancy, just something working, freely available, and easily usable.

Next my thoughts on this.

The solution should have these features:

- Just plain 2A03 with DPCM, to keep things simple.
- Easy way to make music. No text scripts, no hand coding the data as a lot of hex numbers. Either export from a existing NES music editor or from common music format (MIDI, MOD/XM etc).
- Player should be fast, it is both important for demos and games, and data should be compact, it could be important for small game projects.
- Easy way to make sound effects. They could be made exactly same way as the music (think about them as a short pieces of music), or maybe have dedicated editor. Multichannel effects are preferably.
- Sound effects player in addition to the music player. It should be separate, so demos could use music player alone.
- Versions of source code for few popular assemblers (NESASM, CA65, ?), preferably without assembler-specific features to simplify adaptation to other assemblers.
- Free license, which allow everyone to use the solution in any way for any purposes without restrictions, and will not waste time for reading long licensing text with confusing statements.

Connection between the music and sound players could work this way: the music player does not write to the sound registers directly, but instead creates a buffer in RAM. Then the buffer could be sent to the registers (no sound effects), or modified by the sound effects player, and then sent to the registers. Sound effects player could run up to few (2-4) multichannel effects at once, and decide, which channels should play at a time. Triangle channel of an effect could always replace triangle channel of the music, pulse and noise channel could replace music channels if they are louder.


First step is choosing way of creating the music. There are few options: existing NES music editor with a converter tool, use common music format with a converter, completely new editor (least interesting option, requires a lot of work). All these options could be employed if they will use the same data format.

Honestly, from all the available NES music tools I only consider FamiTracker as a candidate, despite it is Windows only. Why not other tools: NT2 has problems with license (Giftware for non-commercial projects); PornoTracker has no DPCM; Neil Baldwin's sound projects use all the resources for music, gamepad control is unconventional for music editors as well. I suppose that instead of using FamiTracker's output and player, only editable module format (FTM) should be used with a custom converter, in order to produce optimal data. Some limitations should be considered for these purposes, like only one column of effects, and maybe not all the effects supported.

Common music formats has both pros and cons. You can't hear the final sound during editing, and have to use converter tool to add the data which you can't edit in the main editor. However, you can choose the editor from few alternatives, and it is easier for non-NES musicians to get started.


Top
 Profile  
 
 Post subject:
PostPosted: Tue Dec 07, 2010 4:23 am 
Offline
User avatar

Joined: Tue Apr 28, 2009 4:12 am
Posts: 469
Interesting stuff Shiru.

I've always used 'virtual' APU registers for my audio engines because it's so much more flexible.

Funnily enough, the synthesis I've developed for my latest project PR8 is actually very, very low CPU usage. It's just that I'm doing 6 virtual tracks, all capable of using all 5 hardware voices at once. This means that the tool ('PR8') is not really for creating music for games/demos but the underlying routines for doing envelopes, vibrato, sweeps etc. All could be done as a little library - it's very easy to use.

Thinking about this, PR8 in a slightly different form could be a very good tool for game/demo music. When I say each virtual track *can* use all 5 hardware voices, that's not to say that *have* to. If you only used one hardware voice per track, it would take only 1 6th of the CPU time.

Also the way PR8 handles the sound/instrument/drum data is engineered for real-time manipulation via the grid sequencer (the sound/instrument data is copied into RAM on every step and then the sequencer trigger data overwrites the required parameters before the next note is played).

This could be changed to be much more efficient if real-time modulation wasn't required. You could also cut down the pattern data (which currently stands at 480 bytes per pattern : 6 tracks x 16 steps x 5 bytes per step) to about 1 5th of the size.

The data for the patterns would then break down into very simple form:

I use $00 = no note, $01 to $50 = normal note, $B0-$FE = tie note (don't retrigger envelopes etc) and $FF = kill the note on the track

As the tracks are virtual, you could dedicate a couple of tracks for sound effects and just define instruments/drums as sound effects (which is really what they are in PR8)

I don't really have time to think about this too much right now but it's definitely a possible solution.


Top
 Profile  
 
PostPosted: Tue Dec 07, 2010 8:48 am 
Offline
User avatar

Joined: Fri Sep 24, 2010 4:41 pm
Posts: 193
Location: California, USA
Shiru wrote:
- Just plain 2A03 with DPCM, to keep things simple.
- Easy way to make music. No text scripts, no hand coding the data as a lot of hex numbers. Either export from a existing NES music editor or from common music format (MIDI, MOD/XM etc).
- Player should be fast, it is both important for demos and games, and data should be compact, it could be important for small game projects.
- Easy way to make sound effects. They could be made exactly same way as the music (think about them as a short pieces of music), or maybe have dedicated editor. Multichannel effects are preferably.
- Sound effects player in addition to the music player. It should be separate, so demos could use music player alone.
- Versions of source code for few popular assemblers (NESASM, CA65, ?), preferably without assembler-specific features to simplify adaptation to other assemblers.
- Free license, which allow everyone to use the solution in any way for any purposes without restrictions, and will not waste time for reading long licensing text with confusing statements.


This sounds like exactly what I am working on, I will definitely post it up when I am done.


Top
 Profile  
 
PostPosted: Tue Dec 07, 2010 9:22 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 21002
Location: NE Indiana, USA (NTSC)
Shiru wrote:
- Easy way to make music. No text scripts, no hand coding the data as a lot of hex numbers.

And all the LilyPond fans say "I resemble that remark."

Quote:
Either export from a existing NES music editor or from common music format (MIDI, MOD/XM etc).

For MOD/S3M/XM, I can make test cases in OpenMPT. But what MIDI editor do you recommend for Windows and Linux so that I can make test cases?

Quote:
- Easy way to make sound effects. They could be made exactly same way as the music (think about them as a short pieces of music), or maybe have dedicated editor. Multichannel effects are preferably.

My current music engine handles drum instruments as sound effects.

Quote:
- Versions of source code for few popular assemblers (NESASM, CA65, ?), preferably without assembler-specific features to simplify adaptation to other assemblers.

Would it be acceptable to have a preprocessor written in Python that takes one master source code file and outputs assembler-specific files?

Quote:
- Free license, which allow everyone to use the solution in any way for any purposes without restrictions

So you want it under what's called a "permissive free software license". Would a requirement to credit the original author, as seen in common permissive licenses such as MIT, BSD, Zlib, and GNU Permissive, be considered "restrictions"?

Quote:
Connection between the music and sound players could work this way: the music player does not write to the sound registers directly, but instead creates a buffer in RAM. Then the buffer could be sent to the registers (no sound effects), or modified by the sound effects player, and then sent to the registers.

Which is pretty much how my current engine works.

Quote:
First step is choosing way of creating the music. There are few options: existing NES music editor with a converter tool, use common music format with a converter, completely new editor (least interesting option, requires a lot of work).

The popular PC trackers are designed to switch all channels in a pattern at the same time, which isn't the most space-efficient especially with a repeating drum or bass line. Among trackers that I remember using, only Famitracker and NT2 allow choosing different phrase numbers for a single step of the order table. So a completely new editor might be worth it, provided I can figure out how to get a PC to communicate with an emulated NES in something like Game_Music_Emu. I can also think of a few ways to do single- and dual-channel echo and chorus that need the ability to start any phrase on any channel at any time.


Top
 Profile  
 
 Post subject:
PostPosted: Tue Dec 07, 2010 10:08 am 
Offline

Joined: Sat Jan 23, 2010 11:41 pm
Posts: 1161
I should say that it was expected that many people has their solutions already. However, this does not help to other people much, because, like I said, there was no freely available solution for many years, and still no it. I think, it is not very useful to tell what your custom solutions is capable, if it is not available or ready for use.

tepples wrote:
But what MIDI editor do you recommend for Windows and Linux so that I can make test cases?

I'm not Linux user, so I don't know which MIDI editors popular there, for Windows there are few free ones and a lot of commercial ones. Free ones are Evolition MIDI, some japanese editor which I can't recall right now, also OpenMPT has some MIDI export functionality, and there is zTracker as well (MIDI tracker).

tepples wrote:
Would it be acceptable to have a preprocessor written in Python that takes one master source code file and outputs assembler-specific files?

It is acceptable as a dev tool, end user should be provided with preprocessed files, because not everyone have Python installed and know what it is, how to use, etc.

tepples wrote:
So you want it under what's called a "permissive free software license".

I personally prefer Public Domain 'license' for these things. Requirement to credit the original author is the restriction, because it is not always possible, especially if there are few authors. A game or demo could not have credit screen, or full font, etc, and you forcing the author to do things he not planned. It should be optional, 'credit if possible'. Also, all these MIT, BSD, etc is the 'long texts', that's really wrong thing to force homebrew devs to read and understand them. They just want to make a project, which never will make any noticeable profit, mostly for fun. They don't want to read a lot of legal stuff instead, it is not fun. Good license for this case is one you can explain in just one line of text, and the line should be 'do whatever you want'.

tepples wrote:
The popular PC trackers are designed to switch all channels in a pattern at the same time, which isn't the most space-efficient especially with a repeating drum or bass line.

I see zero problems here, it is what the converter for, to remove the redundancy automatically. To further reduce the redundancy, converter could break the patterns to very short ones, like 4-8 rows (depends from the order list overhead).


Top
 Profile  
 
 Post subject:
PostPosted: Tue Dec 07, 2010 10:18 am 
Offline
User avatar

Joined: Sun Nov 09, 2008 9:18 pm
Posts: 1107
Location: Pennsylvania, USA
I've made a step in the direction of a general solution, but it may not be for everyone (yet):

Famitracker Exporter plugins

I included my own sound driver as an example, and an example exporter plugin. It has been improved since the initial release, but is not included in the latest release on Famitracker's website yet. I will provide more details when it is available. (I can, however, provide development snapshots to anyone interested)

I know of at least one guy who is successfully using this exporter for his own project and sound engine, and another who I think is considering using it. Obviously I'm aware that my solution is not the best nor the only solution, but I thought I'd mention it in here anyway.

*edit* my solution addresses the following suggested features in the oP:

Quote:
- Just plain 2A03 with DPCM, to keep things simple.


No DPCM in the example driver, just square, triangle and noise.

Quote:
- Easy way to make music. No text scripts, no hand coding the data as a lot of hex numbers. Either export from a existing NES music editor or from common music format (MIDI, MOD/XM etc).


Uses Famitracker, so very easy to create music.

Quote:
- Player should be fast, it is both important for demos and games, and data should be compact, it could be important for small game projects.


The driver is pretty lightweight, but I haven't actually compared it side by side with others so may not be optimal. It's certainly smaller/faster than the famitracker driver, but probably only because it has fewer features.

Quote:
- Easy way to make sound effects. They could be made exactly same way as the music (think about them as a short pieces of music), or maybe have dedicated editor. Multichannel effects are preferably.


It is fairly easy to use famitracker to compose sound effects and graft them into a song that you previously exported. It may need some improvement to be really easy, though.

Quote:
- Sound effects player in addition to the music player. It should be separate, so demos could use music player alone.


My driver is both a music player and sound effect player. Sound effects simply "override" channels that they use while they are playing.

Quote:
- Versions of source code for few popular assemblers (NESASM, CA65, ?), preferably without assembler-specific features to simplify adaptation to other assemblers.


Includes CA65 source and ASM6 source as of the current development version.

Quote:
- Free license, which allow everyone to use the solution in any way for any purposes without restrictions, and will not waste time for reading long licensing text with confusing statements.


Inherits Famitracker's license by association, I guess =)


Last edited by GradualGames on Sun Dec 12, 2010 8:22 am, edited 1 time in total.

Top
 Profile  
 
 Post subject:
PostPosted: Tue Dec 07, 2010 10:41 am 
Offline

Joined: Sat Jan 23, 2010 11:41 pm
Posts: 1161
Gradualore, it is interesting, it definitely goes in the right direction. However, is there any progress since July regarding compiling plug-ins without having MFC? I don't have VC (Express lacks MFC), so I can't make a plug-in. Also, what tepples suggested in the thread, text exporter, would be really useful, it is really easy to parse and to build a converter around it (check how VortexTracker II stores the modules, something like this). If you have VC with MFC, maybe you could make such text exporter plug-in?


Top
 Profile  
 
 Post subject:
PostPosted: Tue Dec 07, 2010 10:48 am 
Offline
User avatar

Joined: Sun Nov 09, 2008 9:18 pm
Posts: 1107
Location: Pennsylvania, USA
The MFC dependencies have been removed. I may not personally have time to develop such a text exporting plugin, but it is a good idea. It should be very easy for someone else to write such a plugin now that the plugin system is in place. If I reach a lull in my game project and have some extra time I may write such a plugin. Til then, any interested individuals are invited to write their own plugins. I can try to provide assistance to anyone who would like to ramp up on it.


Top
 Profile  
 
 Post subject:
PostPosted: Tue Dec 07, 2010 11:02 am 
Offline

Joined: Sat Jan 23, 2010 11:41 pm
Posts: 1161
So, where I can get the source code of your example exporter plug-in with removed MFC dependencies?


Top
 Profile  
 
 Post subject:
PostPosted: Tue Dec 07, 2010 11:03 am 
Offline
User avatar

Joined: Sun Nov 09, 2008 9:18 pm
Posts: 1107
Location: Pennsylvania, USA
If I get a chance tonight, I'll try to put together a development snapshot and post a link in this thread and in the famitracker plugins thread.


Top
 Profile  
 
PostPosted: Tue Dec 07, 2010 11:31 am 
Offline
User avatar

Joined: Mon Jan 03, 2005 10:36 am
Posts: 3141
Location: Tampere, Finland
tepples wrote:
The popular PC trackers are designed to switch all channels in a pattern at the same time, which isn't the most space-efficient especially with a repeating drum or bass line. Among trackers that I remember using, only Famitracker and NT2 allow choosing different phrase numbers for a single step of the order table. So a completely new editor might be worth it,

Nothing stops the tracker from optimizing the patterns per channel when exporting. It doesn't matter how they are stored in the module (or edited in the tracker). Same is of course true for a program that converts IT/XM/... to a different format.

tepples wrote:
provided I can figure out how to get a PC to communicate with an emulated NES in something like Game_Music_Emu.

Not too hard using Nes_Snd_Emu, you don't need Game_Music_Emu for it.

E: I can also probably add text mode export to Pornotracker, if we can standardize the format first. (One problem is differing instrument formats.)


Top
 Profile  
 
 Post subject:
PostPosted: Tue Dec 07, 2010 12:07 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 21002
Location: NE Indiana, USA (NTSC)
Shiru wrote:
for Windows there are few free [standard MIDI file editors] and a lot of commercial ones. Free ones are Evolition MIDI

Google doesn't appear to turn up any relevant results.

Quote:
tepples wrote:
Would it be acceptable to have a preprocessor written in Python that takes one master source code file and outputs assembler-specific files?

It is acceptable as a dev tool, end user should be provided with preprocessed files, because not everyone have Python installed and know what it is, how to use, etc.

Not everybody has an assembler installed. Not everybody has an image converter installed.

Quote:
tepples wrote:
So you want it under what's called a "permissive free software license".

I personally prefer Public Domain 'license' for these things. Requirement to credit the original author is the restriction, because it is not always possible, especially if there are few authors. A game or demo could not have credit screen, or full font, etc

BSD license allows the credit to be placed in the manual, not necessarily the game program itself.

Quote:
Also, all these MIT, BSD, etc is the 'long texts'

I thought "long texts" were GPLv3 (35821 bytes), LGPLv3 (43637 bytes), Apache v2 (11558 bytes). Compare to MIT (1092 bytes), BSD (1493 bytes), zlib (998 bytes), and GNU Permissive (285 bytes).

Quote:
Good license for this case is one you can explain in just one line of text

This is the GNU Permissive License. Resize your browser window ;-)
Quote:
Copyright 2010 Damian Yerrick

Copying and distribution of this file, with or without modification, are permitted in any medium without royalty provided the copyright notice and this notice are preserved. This file is offered as-is, without any warranty.


Quote:
I see zero problems here, it is what the converter for, to remove the redundancy automatically.

Looking at a list of notes and finding all the repeated parts that can be factored out into phrases, balancing order list overhead vs. repeated data in patterns, is as hard as writing a compression program. Writing a music editor might be easier than this.

Quote:
To further reduce the redundancy, converter could break the patterns to very short ones, like 4-8 rows (depends from the order list overhead)

Which is where the tradeoff comes. At one byte per note, order list overhead for 8-row phrases becomes significant, and it won't easily find 12-row phrases of a compound-meter song.

Quote:
and of course there should be RLE for empty rows.

For example, my engine allows 0, 1, 2, 3, 5, 7, 11, or 15 empty rows after each row.

thefox wrote:
Nothing stops the tracker from optimizing the patterns per channel when exporting.

Other than the lack of people's time to find an efficient algorithm that searches for repeats shorter than full-pattern repeats.

Quote:
Not too hard using Nes_Snd_Emu, you don't need Game_Music_Emu for it.

I was planning on writing the playback code in 6502 assembly language, so that I don't have to maintain parallel copies in C++ and in 6502 assembly language and verify by hand that they operate identically.


Top
 Profile  
 
 Post subject:
PostPosted: Tue Dec 07, 2010 12:19 pm 
Offline
User avatar

Joined: Mon Jan 03, 2005 10:36 am
Posts: 3141
Location: Tampere, Finland
tepples wrote:
thefox wrote:
Nothing stops the tracker from optimizing the patterns per channel when exporting.

Other than the lack of people's time to find an efficient algorithm that searches for repeats shorter than full-pattern repeats.

That is if you really need to go for "optimal". I'm sure most apps would be fine with just pattern based optimization.

It's always a tradeoff between speed and size, and different applications have different needs.


Top
 Profile  
 
 Post subject:
PostPosted: Tue Dec 07, 2010 1:08 pm 
Offline

Joined: Sat Jan 23, 2010 11:41 pm
Posts: 1161
@tepples

I'd prefer to not have an argue just for argue here. I know how difficult to program a tracker (has made few) and optimizing converter (as well), so I don't believe these arguments that it could more difficult to make an optimizing converter (few hours to days of work) than a tracker (months to years of work).

You provide many details about your engine, do you want to offer it, or what? If not, why other people need to know these details?

tepples wrote:
Not everybody has an assembler installed. Not everybody has an image converter installed.

For me it is pretty obvious that having an additional uncommon tool for very small task that could be done by one man (before releasing an update) instead of every user (after downloading an update) is clearly unoptimal approach. It is understandable that someone who want to change the source code should use the tool, but forcing every user to use it is wrong.

Regarding licenses, it would be much more useful if you would just say why you think one you propose is better.


Top
 Profile  
 
 Post subject:
PostPosted: Tue Dec 07, 2010 4:20 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 21002
Location: NE Indiana, USA (NTSC)
Shiru wrote:
I know how difficult to program a tracker (has made few) and optimizing converter (as well), so I don't believe these arguments that it could more difficult to make an optimizing converter (few hours to days of work) than a tracker (months to years of work).

If you're willing to work on this optimizing converter, I have some sequences for you to try them on in order to see what kind of patterns you can extract. But I read the description of how Pucrunch represents the file to be compressed as a graph, and I had trouble wrapping my head around it. It sounds like something where a greedy algorithm might not produce the best result.

Quote:
You provide many details about your engine, do you want to offer it, or what?

Eventually, yes. Right now it depends on .byt statements, but I have a half done MCK-style assembler for music sequences.

Quote:
For me it is pretty obvious that having an additional uncommon tool for very small task that could be done by one man (before releasing an update)

The PKZIP archive format isn't good at handling archives containing multiple nearly-identical files.

Quote:
Regarding licenses, it would be much more useful if you would just say why you think one you propose is better.

The implied warranty could lead to product liability claims, and it appears to take a disclaimer to protect the author from such claims. See for example Mortenson v. Timberline. Free software licenses have such a disclaimer; public domain status does not. Among free software licenses that disclaim implied warranties, the GNU Permissive License is the shortest that I've ever seen.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 35 posts ]  Go to page 1, 2, 3  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group