Unless I fucked up with the code you should be able to link or embed the video here:

Andrew:

Depends. They're different beasts. I personally prefer to code music in MML, but back in the day I worked both with MuSICA and FAC Soundtracker / Moonblaster. We did everything in this music disk with Moonblaster (I did this first song, by the way). Almost everything we did for the Draken Magazine was done with MuSICA.

I'll try and post a video when I have some time.

Comparing with modern day music tools, the trackers suck indeed, but.....

back in the day i created my music in FAC soundtracker and it is just what you are used to.

Trackers and MML both have advantages and disadvantages. The main advantage that MML has is that it is close to sheet music, so actual musicians could use it. Trackers appeal to people without a musical background, offering a more lego-like way of writing music.

For MoonSound Music Studio (MS²), which uses a MML back-end, but currently tracker front-end, I'm constantly trying to figure out how to combine the best features of both MML and trackers.

One thing that is interesting is horizontal versus vertical channel orientation. FAC Soundtracker, the first MSX tracker, used horizontal orientation. All the others modelled themselves after the Amiga and PC trackers and went vertical. Strangely, scrolling tracks with more than 16 steps, or separate effect columns were not popular on MSX, while in my opinion these things are the main motivation for a vertical layout.

However, horizontal display resembles sheet music much closer and also makes a lot of sense for performance reasons in MS² (due to the MML back-end, which groups data on a per-channel basis instead of combining/interleaving all channels on a single step). Additionally, DAW and pianoroll software also has horizontal display.

So I've pretty much made up my mind that MS² needs a horizontal layout. The only question is, should I go out of my way to retain the vertical layout?

Both have their uses. Like GuyveR800 says, each has their pros and cons.Besides, there is excellent music created with both types of software so I think it just comes down to the user.

Software-wise, I prefer tracker over MML editors. Better overview on what notes and effects are played at what point in time due to its grid-like layout and (in some cases) separate instrument/volume/effect channels, compared to having one "paragraph" with notes, volume/portamento/whatsnot per musical channel.

Imho the problem we have on MSX is, that the most commonly used tracker is Moonblaster (1.4 or the Moonsound variants). While those trackers may have been advanced or groundbreaking at the time of their release, when I first tried MB1.4 around 2013, I felt I was taking a huge step backwards after using different windows trackers and pianoroll-based music editors.

Luckily there are some new trackers in the works/released like Trilotracker and MS2, so things are getting slowly better.

My workflow is to use a more modern music program to create a song.

Converting this to MIDI, and then into MML is then a very mundane task to accomplish. Because MML is such a widespread format, there are a lot of available utilities to do this.

From there, it's really a simple copy paste job into MusicA.

The availability of PSG and FM VSTs along with MIDI controller input in a modern program really make it difficult to sit on an MSX and try to compose music. It's clumsy.

I agree. if MSX had a way to feed a MIDI file in directly, that would be pretty great.

It's a bit of a difficult task though. The MIDI file would need to be very specifically made so that it imports right.

Otherwise, you could import some like 24 channel disaster that isn't possible, and you'd get awful results.

I don't think it will be hard if someone created ...

Yeah, that "...if someone [else] created..." is what I keep hearing again and again. :-)

MIDI does not have channels, it has polyphonic tracks, each of which can take up anything between 1 or upwards of 20 channels dynamically.

Meridian actually supports MIDI file loading, and it gets around the quantization issues by its confusing delta-step time feature.

Many years ago I wrote a standalone MIDI to MBWAVE convertor (also MOD to MBWAVE and some other convertors), so I'm confident that I can make it work. Just need more time and motivation to work on it. I had hoped there would be more interest in MS², the lack of which has caused me to lose focus...

By the way, MS² is not meant to remain "MoonSound Music Studio", because as soon as the MoonSound functionality is done, I will add other soundchips and then MS² will mean "Multiple Soundchip Music Studio" or "MSX Sound & Music Studio"... I haven't decided yet :)

@ GuyveR800

MS², the beta testing version, is available right, and people can join in via a small donation?

Do you have a youtube video of it to demonstrate it's current capabilities or screenshots?

I would be interested to see it's user interface and such.

By the way, MS² is not meant to remain "MoonSound Music Studio", because as soon as the MoonSound functionality is done, I will add other soundchips and then MS² will mean "Multiple Soundchip Music Studio" or "MSX Sound & Music Studio"... I haven't decided yet :)

So, 'MSX' will not be anymore the only MSX-related abbreviation with several meanings or interpretations ! :)

I had hoped there would be more interest in MS², the lack of which has caused me to lose focus...

Well, for starters, it's kind of a niche product. The proportion of people who will be interested is small to begin with.

However, for those who could be interested (I guess I would be one), the website is very terse. There's a wall of very small text with some technical details. Nothing to draw attention.

I think that if you want more involvement, you should at the very least add a few screenshots, a video showing some of the current capabilities, and a short list of features. And for those who'd like to be beta testers, a list of the features in the program's current status, and an estimate of when it will be completed.

Also, get a PayPal account. A 15 euro bank transfer to a bank in The Netherlands would cost me around 45 euro in fees. I guess the situation is similar for other people in other countries.

@Javi: There is a Paypal account, but you need to be careful with the general paypal fees and possible currency conversion fees.

You're right that the website could use more media and stuff. The entire TNI site is like that ^^; I've been meaning to update it, but I prefer to spend time doing actual development.

@George: Yeah there are some youtube videos. For example this one that walks you through some of the User Interface things too:

MIDI does have channels. It's literally in the specification for them. However, they, being MIDI, behave a little differently than you might expect since they do all kinds of crap. (You assign devices to MIDI channels, etc.)

Anyway what I meant by channels is more like "24 tracks", or "24 channels" as you would see in MusicA, or any tracker (Each column) which isn't actually possible, even with MSX-MUSIC, SCC, and PSG combined.

To be completely specific and remove all doubt:

In a modern DAW you can just create channel after channel (track after track. pick a word. it varies depending who you ask and what you're doing. I am calling them trackles). and layer it all together.

Sometimes, these trackles are polyphonic, sometimes they're not.

Doing all of that with little consideration for putting it on an MSX is a great way to create an audio file that doesn't really do much for MSX.

You can't have polyphony on any given MSX channel.

I can create a tune in FruityLoops right now with far too much polyphony for an MSX to handle, and export to MIDI. It will function fine as a MIDI file as well.

So when you're making MIDI files with the intent of importing into MSX, you basically have to create monophonic channels. Chords have to be broken into separate channels.

You'd need to write one hell of a converter to properly breakdown polyphonic channels into separate MSX sound channels, and if it's not exactly right, it won't all fit anyways.

You're better off just doing it yourself ahead of time. I do this for all the music I write that ends up on MSX or PC Engine.

You'd need to write one hell of a converter to properly breakdown polyphonic channels into separate MSX sound channels, and if it's not exactly right, it won't all fit anyways.

You realise that cheap-ass FM synths are doing exactly this with far less processing power than an MSX? These synths are using exactly the same soundchips.

Mapping polyphonic MIDI "channels" to soundchip hardware channels is a basic function and there's no reason why a convertor (especially one that's not realtime) would have any problem dealing with this.

For realtime MIDI input, I think most synths will output only one MIDI channel with polyphony (or 2 in case of split keyboard or layered patches). So that's not a big deal either.

You have fundamentally missed the point of what I said.

You can create, and there exist, plenty of MIDI compositions that contain more polyphony than an MSX can actually handle.

So, you could be writing songs that don't actually transfer properly to the MSX.

There is definitely problems to be had, and it's a bigger deal than you apparently think.

I have a few files right in front of me with 15+ voices of polyphony. Without the use of multiple sound expansions, you can't hit 15 note polyphony.

Now what.

What will you do if you send that many notes all via MIDI channel 1 to the MSX? What happens? Do you just bleed the notes into each available chip round robin and probably butcher the intended sound for chords and such?

Will you set each available chip in the MSX to a different MIDI channel and just drop any note after each chip's limit and hope the input MIDI is communicating accordingly?

Good luck writing a MIDI converter that can do that sort of stuff better than just planning ahead while writing the song, lol

Those cheap ass FM synths you are talking about aren't even doing what you're stating that they do. They don't intelligently create polyphony. They just play what is fed in and it either works, or it sounds like shit.

Another good example is some of the MIDI that went down in games on MT-32 and such. That's not even a cheapass module. Those were kind of expensive. Some stuff sounded mental on it in games due to weird things with polyphony, and sound effects.

The point I am making is that you don't just magically take a MIDI and have it magically sound perfect on an MSX. If you don't compose it with the hardware in mind, good luck.

I anxiously await someone's converter that takes like, 32 note polyphony and can intelligently assemble and convert it to an MSX version that still sounds good.

There is a Paypal account, but you need to be careful with the general paypal fees and possible currency conversion fees.

Those fees aren't that high. I use PayPal regularly. In any case, the main difference (even leaving aside the 45 euro fee for international transfers) is that with PayPal I can click a button on your website from my computer and send you the money in a couple minutes.

With a bank transfer I have to write your account number down and then find time to go to the bank, stand in line, and fill a few forms to send you the money. It's unlikely to happen.

If you want people to get involved, make things easy for them. :-)

That demo video is cool. Can you split it in two? One showing the interface, another just with the song. Then put those in the website complete with a short, easy to read list of the main functions, and then we have a winner.

With a bank transfer I have to write your account number down and then find time to go to the bank, stand in line, and fill a few forms to send you the money. It's unlikely to happen.

Here in The Netherlands, we can just use our phones or pc's to do the transfer in less than 2 minutes with IBAN. I don't know about international fees though.

But i do agree PayPal is fast and the fees and literately for let's say 15 euros around 75 cents, there are online calculators for that. There are also calculators for regular IBAN bank transfers, those seem more expensive, but also depending on between which countries the transfer is and what banks are involved etc etc.

Back on topic:

MS² looks nice!

And about the polyphonic MIDI stuff, It seems logic to know when making something on the pc with MIDI tracks, that things stay within boundries if you want to port it to MSX.

The point I am making is that you don't just magically take a MIDI and have it magically sound perfect on an MSX. If you don't compose it with the hardware in mind, good luck.

Nobody was claiming this, but as you seem to be keen on making this point, I will address it. The same hardware limitations that MSX has also exist on actual MIDI equipment. Most of the synths I've seen handle a maximum of 24 notes of polyphony, but cheap synths will only have 5 or 9, this is in their specs. Actual MIDI synths will employ strategies for dealing with too much polyphony, which you gave a few examples of.

Those cheap ass FM synths you are talking about aren't even doing what you're stating that they do. They don't intelligently create polyphony.

I'm beginning to doubt your ability to read. Where did I state that they intelligently create polyphony?

They just play what is fed in and it either works, or it sounds like shit.

This "just playing what is fed in" requires dynamically mapping the polyphone MIDI channels to actual soundchip hardware channels, just like any converter on MSX would have to do, like I already said.

So when you're making MIDI files with the intent of importing into MSX, you basically have to create monophonic channels. Chords have to be broken into separate channels.

This is simply not true, which was the point I made in my previous post. There are no significant technical hurdles to dealing with monophonic MIDI channels,

Without the use of multiple sound expansions, you can't hit 15 note polyphony.

eh? MS² has 42 notes of polyphony, using MoonSound alone.

I anxiously await someone's converter that takes like, 32 note polyphony and can intelligently assemble and convert it to an MSX version that still sounds good.

Again, FORTY TWO notes of polyphony are possible in MS² currently (limited only by hardware, technically it can handle more than 250 channels without recompiling), so I expect not a single problem (channel-wise) handling this scenario.

There are no significant technical hurdles to dealing with monophonic MIDI channels,

This should say "There are no significant technical hurdles to dealing with polyphonic MIDI channels, compared to monophonic MIDI channels."

This should say...

Sorry you can't edit messages yet. I'll work on that a few days after the launch. Once everything is running fine I want to rest at least one weekend.

Nobody was claiming this, but as you seem to be keen on making this point, I will address it. The same hardware limitations that MSX has also exist on actual MIDI equipment. Most of the synths I've seen handle a maximum of 24 notes of polyphony, but cheap synths will only have 5 or 9, this is in their specs. Actual MIDI synths will employ strategies for dealing with too much polyphony, which you gave a few examples of.

Yeah, I don't care if anyone has made the claim yet. I'm making it because it's a thing to consider.

Especially if you're composing MIDI tunes on a PC with a fancy DAW. You can create wildly polyphonic stuff that will fall apart on old FM synths due to lack of available polyphony.

Many of those old devices were intended to be one of many instruments in a performance, whereas PCs have it all in one.

So, I am curious how you might be handling the overflow of polyphony. Most of those old toy ones don't even hit 24 notes. Some are 12. and some only support like, one MIDI channel / voice change and get weird.

In any case, it's not a lot, and if you try using it as a tone module for a fancier MIDI tune, it will either error at you, or sound like total shit. They specialize in playing stuff that was made with those devices in mind, or operating as one piece of a song.

There's a reason people aren't hooking old Yamaha toy keyboards up to their PCs for DOS gaming, lol. Everyone goes for a Soundcanvas or MT-32 basically.

I'm beginning to doubt your ability to read. Where did I state that they intelligently create polyphony?

*Properly. Same difference really. Properly would imply it was done intelligently, lol.

I've found that feeding heavy polyphony into an older, goonier MIDI device will yield "proper results" that sound pretty wonky or just wrong. Or, it will just go "no" and not work. It gets a bit subjective if the software is left to interpret how to attempt to effectively "down polyphony" the polyphony.

You could try to do all kinds of things to try and interpret and give a best approximation given limitations. For example, lots of 3 note chords can have one of the notes dropped off and still sound about the same. That can get complicated, though and requires a lot of musical theorying.

This "just playing what is fed in" requires dynamically mapping the polyphone MIDI channels to actual soundchip hardware channels, just like any converter on MSX would have to do, like I already said.

Yes, I'm aware, that's why I am asking what exactly your plan is in a non-Moonsound environment?

What will be done when it's MSX-MUSIC + SCC + PSG only or something? There are obvious limitations and sound differences to that setup. Will you fudge it as best as possible, or just display an error and go "This is not going to work right.".

I don't think there are any other MSX programs that support this. Dynamically mapping stuff to FM+SCC+PSG is going to result in a pretty interesting rendition of a song.

This is simply not true, which was the point I made in my previous post. There are no significant technical hurdles to dealing with monophonic MIDI channels,

Did you mean "technical hurdles to dealing with polyphonic midi channels" ? And, what I am talking about is at the composition level. Yes, you can probably (with shades of gray) barf polyphonic MIDI in and let a converter hopefully do it right.

But depending on how said conversion handles mapping polyphony to the MSX's available sound chips, you would likely be better off breaking polyphonic things (chords) apart yourself, and explicitly mapping them so you get exactly what you want instead of hoping for the best.

Case in point: That's what I do for Inferno. I am creating MIDI tunes, but each track in the software corresponds to each FM channel. This makes copying it into a MusicA file a whole lot easier since it's not a clusterfuck. They go where I planned for them to go. No guess work, dynamic mapping, or real thought at all really.

eh? MS² has 42 notes of polyphony, using MoonSound alone.

Again, FORTY TWO notes of polyphony are possible in MS² currently (limited only by hardware, technically it can handle more than 250 channels without recompiling), so I expect not a single problem (channel-wise) handling this scenario.

I left Moonsound out of the equation. I don't (and probably won't) own one. This discussion wasn't MS2 specific, anyways. I am aware that Moonsound basically has no concerns with polyphony. I was more curious about the more "standard" MSX setups. There are wildly obvious limitations to an MSX with just an MSX-MUSIC+PSG, etc.

How will you be handling all of this in the absence of a Moonsound unit?

There's obviously a lot of approaches to it.

EDIT: Oh. You edited your polyphonic typo in the other thing. I completely missed it.

lol. The irony.

Currently MS² is a MoonSound program, and it's the program I'm writing so it's the program I can discuss technicalities on, instead of generally discussing issues that may or may not actually exist.

As I mentioned before, Meridian can load and play standard MIDI files on MSX without them needing any special care, but I didn't write it so I don't know exactly how it does what it does. Since it also requires MoonSound, you're probably leaving it out of the equation...

As for your question about how MS² will handle a non-MoonSound environment, it will still be able to load MoonSound songs even if you don't have one. The same counts for eg. a SFG-05 song without having a SFG-05 module, or loading a MIDI file.

I have plenty of ideas to provide tools, hinting and intelligent automation in MS² to allow a song to be played on various devices without having to make a separate version of it. Compose once, play everywhere.

MIDI support for other things than note input was not actually on my todo-list, but now that you made me think about it, it sounds easy enough. I know at least one beta-tester that will be excited :)

Yeah, with a Moonsound cartridge, the polyphonic issue kind of goes away, as it's got enough channels to not go a bit moronic with it, and they are all capable of the same sounds.

I thought Moonsound *also* supported MSX-MUSIC/PSG (and SCC?) , and in that environment, that ability sort of falls over on it's face.

and yeah, I like Meridian, but don't have Moonsound.

I was curious how any MIDI input/conversion would be able to intelligently handle MSX-MUSIC+PSG+SCC at most.

Mainly just MSX-MUSIC + PSG, since that's probably the most common *thing for games*. It would be nice to have an updated MusicA that maybe supports a mouse cursor and has a context menu or tool bar to get to the various menus.

Having it convert MIDI --> MML wouldn't be so bad, either.

I thought Moonsound *also* supported MSX-MUSIC/PSG (and SCC?)

MoonSound is a OPL4 cartridge, so it doesn't "support" MSX-MUSIC, PSG or SCC. Perhaps you mean MoonBlaster for MoonSound, the tracker. It doesn't support those things either, just pure OPL4. In fact, the most popular version of MoonBlaster for MoonSound (MBWAVE) doesn't even support the FM part of the OPL4!

saikokrasha:

Software-wise, I prefer tracker over MML editors. Better overview on what notes and effects are played at what point in time due to its grid-like layout and (in some cases) separate instrument/volume/effect channels, compared to having one "paragraph" with notes, volume/portamento/whatsnot per musical channel.

That has more to do with the style of the programer than a quality of mml itself. It's similar to how coders have different styles of organizing, indenting and commenting their code. I don't use MusicA so I can't attest that you have options besides a single channel header and tons of channel data until you move onto the next channel. But in many other mml dialects, you can (and should!) break up each channel's data for readability.

Take this for example https://www.mmlshare.com/tracks/view/1060 where everything is broken up into phrases of the song. With the exception of the heavy interlacing of effects and instrument changes, it's fairly easy to pick a line, say the NES triangle on channel C, and follow along to what it's doing.

Or this example https://www.mmlshare.com/tracks/view/1007 where I use a lot of whitespace and the result is that it's super easy to follow along with what's going on. Also you can indeed see all the effects at a glance because they're placed in a line above the lines with actual music notes.

I also have been lately visually aligning similar music phrases so that they look vertically aligned from one phrase to another https://www.dropbox.com/s/n65tu7sbnctu0ib/themefix.mus?dl=0

Xyz:

I hadn't heard about MMLShare before. I see the sytnax is different from other MML versions I've seen before (MSX-BASIC's own and MuSICA). I'm not a musician (I suck at composing), but I did some tracks in MuSICA long ago when I was a teenager.

Glad to see other implementations from another platforms!

@Andrew: Oh, no, MS² does not currently support MSX-MUSIC and MSX-AUDIO yet, just MoonSound. They are planned to be supported at some point, but probably not before the first release.

They are basically subsets of the MoonSound functionality, so it's fairly easy to support them. Depending on demand and amount of work required, it might be included in the first release afterall.

So, the way MS² deals with songs written for sound extensions you don't have, is that you can load them but you can't play them, until you've set up a configuration for that particular (set of) chip(s). A configuration consists of a set of instruments to use, and probably some other stuff (that I haven't fully thought out yet).

A song will then be able to include multiple configurations, all sharing the same song data. So a single song could support MoonSound, MSX-MUSIC+MSX-AUDIO in stereo, 4 SCC's, SFG-05+MSX-MUSIC, and even just PSG.

Like I said, MIDI is currently only supported during the instrument menu's. The plan is to allow MIDI to be used for note input in the first MS² release. Import of MIDI files is also on the wish-list (as is import from as many other formats as are feasible).

However, I've already had requests for MIDI playback, so if there is enough demand I suppose I could make MIDI a first-class citizen, allowing you to create MIDI songs. It should make MIDI file import even easier :)

Yeah, MML that is just a blob of text with no formatting is generally

A) Copy pasted from somewhere else and only verified by hearing

B) Done by a lunatic

http://benjaminsoule.fr/tools/vmml/

This thing is neat.

@Guyver: Oh. Yeah, I always thought it was supporting everything. Is Meridian the only one that supports MIDI + MSX-MUSIC/etc.?

AFAIK, they never finished that software, anyways.

Pretty sure Meridian doesn't support MSX-MUSIC either...

There was an old version of it that did, but it was cancelled when the MoonSound version was made.

The one I messed with used MSX-MUSIC, IIRC.

the interface didn't look like the most recent one I saw. Maybe it was using Moonsound too. I was just opening the pack-in tunes and poking around.

This was back when Wolf and them were giving me the legit worst advice about MSX ever.

and when Wolf said FM can sound like SCC, and well

being deaf is a thing sometimes.

I've recently discovered MML format and I'm really interested in using it in MSX. I see a main advantage compared to traditional trackers: it's an standard. I mean, if you develop and MML player for MSX-Music, no mather what program uses musician to compose if it can export in MML format.

MSX trackers has a serious problem with format since everyone has its own format and you need to know it in order to develop a driver. MML is universal, and for example korean guy sharskym has developed a MML library for MSX-Music ( https://www.youtube.com/watch?v=TOrA93uKX8c ).

Is there any MSX tracker for MSX-Music that exports in MML format? Where can I find MML musics for MSX?

Is there any MSX tracker for MSX-Music that exports in MML format?

Not that I know of, but you can use MuSICA to compose music directly in MML. It supports PSG, FM and SCC.

If you haven't used it before, there's a very detailed article in the October 1990 issue of MSX Magazine, pages 58-66 (yeah, in Japanese):

About the songs... Well, I think there was an archive of .MSD songs in msxarchive.nl, but I'm not sure it's still there. You can check some MSX Magazines, because from the February 1991 issue they have a section called "MuSICA WORKSHOP" where they publish songs:

.MSD is file format from MuSICA or directly MML musics? I'm interested in testing driver done by Sharkskym.

Thanks.

MSD is the format of MuSICA. it's slightly different than FM-BASIC format.

You're right that MML is a "standard", but the details differ :P

FM-BASIC (PLAY #2) and MIDI-BASIC (PLAY #1) are already much more advanced than regular MSX-BASIC (PLAY).

I've read your comments on that other site regarding writing convertors versus integrating various replayers. I must say that writing convertors do not seem to be worth it, if you do not control the target player (in your case FM-BIOS). It would take a lot more time to write a convertor (especially a lossless one), than it would to simply integrate the respective replayers.

I've tried to integrate MoonBlaster driver in my MSX-C engine with no success. Even some experienced guy with C like Artrag in MRC tried it but the result is a very defective driver. ASM players are not really drivers as we can consider in a compiled environment as MSX-C / DOS2. They do very specific things as use of fixed memory addresses or page switching, and in a generic environment these task must be executed at higher level (compiler / DOS), so you get a hang up.

At this point I have a quite reasonable converter from MB to FM-BIOS format (still needs some work) and yes, it has been a hard works. This is the reason to desire a standar format, I don't want to face a new driver / converter every time a tracker is developed.

Anyway of you know any driver suitable for DOS2 it should be apreciated ;-)

Anyway of you know any driver suitable for DOS2 it should be apreciated ;-)

Moonblaster 1.4 works with dos2 and I assume the moonsound versions as well (I havent looked or tested this) :)

You can download a DOS2 compatible version of the MB 1.4 driver, written by BiFi, on MSX Banzai! I don't know how easy it is to integrate into MSX-C, but perhaps Javi can help with this. My only experience with C on MSX was using the SDCC cross-compiler.

Anyway, I agree that there should be one standard to rule them all. This is why I'm writing MS² :) And this is why I know that writing convertors takes A LOT of time.

I've tried to adapt that driver, and I can ensure you that it's not a trivial work to adapt to DOS2 environment. As I have commented a few lines above, even experienced people with ASM and C has tried it with no success. Probably @Javi Lavandeira would face the same problems, the idea behind a driver for a DOS2 environment using compiled languages is to design "black box" not depending the program that uses it (dinamic memory allocation, don't make page switching, don't change ISR, etc).

All drivers we are designing for our engine tries to work as described.

Apart from the updated MoonBlaster 1.4 BASIC driver, I also did similar fixes in the MoonBlaster for MoonSound Wave and MoonBlaster for MoonSound FM BASIC drivers. These are all 100% DOS2 supported now. I have yet to release the fixed MoonBlaster for MoonSound BASIC drivers, although a fixed version for the Wave driver is already available on the Dutch MoonSound Veterans collection disks. That version also includes a bugfix that allows to use all 48 defined Own Waves.

The editors are still not (or partially) DOS2 supported, although I did hack a MBWAVE 1.16 with the 48 Own Waves fix and the correct default for 60 Hz equivalent speed setting.

Sorry but to me it sounds like there is something you are missing in MSX-C to load and call external code. Like I said, I don't have experience with MSX-C, but given the professional nature of this compiler, I would be really surprised if any ASM code would require much modification.

Anyway BiFi's driver is already working in DOS2, so I don't understand the "non-trivial work to adapt it to the DOS2 environment" :/

My bad, it's been a few years since I used it, indeed it was the version by BiFi. I recall running into some error/problems but BiFi fixed it in a few minutes for me so I think it is not that hard (you just need to know where to look/what to do).

@Javi: Perhaps this thread can be renamed to a title more fitting of a "generic music editor discussion" ? Since it is no longer about tracker sucking (although we are pointing out flaws/problems in existing tracker software amongst others :) )

Maybe I should release "MBMSTNI". This is the merged MBFM and MBWAVE program that I created which can load, edit, play and save both MFM and MWM, with full DOS2 support, the abovementioned bugfixes, plus many more bugfixes...

Back in the day I decided against releasing this app, and instead continue working to turn it into MS². Now that I'm thinking about it, it might be a nice present to MS² donators, so they will at least have something that is fully functional...

@Krasha Saiks:

@Javi: Perhaps this thread can be renamed to a title more fitting of a "generic music editor discussion" ? Since it is no longer about tracker sucking 

Well, not completely. The initial post mentions MML.

Anyway, feel free to create a new thread any time. :-)

This was mostly a cheeky test thread to see if anyone replied.

and, any conversation about trackers is about them sucking.

ayyyyyyyyy. :) lol

I looked into this. The MB driver won't work out of the box with MSX-C code because of the way the MSX-C runtime works with interrupts.

I have been busy, so I didn't look deeper into this.

There are a few things to consider when adapting the MB driver for C. I'm not that familiar with MSX-C and its internals, but aside from what Javi wrote, there is also the memory mapper and the H.TIMI hook bending to adapt. Loading files is done with normal C file access functions. It fully depends on the how the compiler handles those if it'll use FCB or File Handles. That way full DOS2 compatibility is ensured. I can take a look at adapting the source to something better usable for C, but I will need help with MSX-C and its internals.

Of course this does not only apply to MSX-C. If it is possible to make it usable with other C compilers that run on MSX computers, some sort of bridge can be made for that as well.

I can take a look at adapting the source to something better usable for C, but I will need help with MSX-C and its internals.

It should be great, not only for that MB driver, but any other ASM driver. I can help you with any doubt, I'm not a high expert in MSX-C but count with my help :-D

Other driver that I've tried is ayFX, it compiles with no error, but when I try to use inside MSX-C code it doesn't produce any sound. Doesn't hang up as MB driver, simply does nothing. At the end I've developed my own ayFX driver in pure C that works like a charm.

You realise that cheap-ass FM synths are doing exactly this with far less processing power than an MSX? These synths are using exactly the same soundchips.

Of course, technically, it's not hard to implement Dynamic-Voice-Assignment algorithm on cheap 8bit system.

However, you should remember one important thing: MSX has to do also other than musical performance in most cases.

In FM synth, all resources are implemented to be used for musical performance, unlike in PC.

However, you should remember one important thing: MSX has to do also other than musical performance in most cases.

In FM synth, all resources are implemented to be used for musical performance, unlike in PC.

I agree. This is one of the problems I see with all the music software released for the MSX: Music tracks are always tied to hardware channels, and it is up to the composer to assign the notes in every channel in order to simulate effects such as reverb/echo, or polyphony by multiplexing several notes in turn in a single channel.

I'd like to see some music application that decoupled the hardware from the actual MML or channel track. Ideally, the artist would enter sound data via MML, including effects (such as echo) and chords in the same single MML string, and the software would manage the available channels and assign what's playing in each of them.

Of course, this would require more processing power. The song data would have to be "compiled" into a stream of data that can be sent directly to the sound chip registers.

Generally, it depends on its purpose what functionality is required for musical software.

If you want to make your MSX as musical instruments, it isn't hard to write the software like an FM synth.

However, you might not able to do anything other than music on your MSX instead:)

Actually, the early General MIDI instrument using OPL4 is implemented with 8bit CPU.

I believe someone can rip and port its firmware to MSX and MoonSound;)

BTW, I wrote software that works like an FM synth integrated multiple real sound chips for a Windows PC, but uses a lot of resources despite on modern PC.

Threads are evolving from one thing to another ;)

A bit off topic, but on topic on some level. MSX-C has the possibility to call slots, subrom etc. also you can call stuff in several ways, but never used it. (to answer パトリク somewhat).