Author Topic: It's MML time.  (Read 3421 times)

esteban

  • Hero Member
  • *****
  • Posts: 24063
Re: It's MML time.
« Reply #60 on: April 06, 2010, 10:21:05 AM »
...here is an MP3 of it, for your listening pleasure!
http://www.aetherbyte.com/downloadables/Aetherbyte.mp3



Just listened to this, the third track really is wonderful

Dig the percussion, IN STEREO :)
  |    | 

Arkhan

  • Hero Member
  • *****
  • Posts: 14142
  • Fuck Elmer.
    • Incessant Negativity Software
Re: It's MML time.
« Reply #61 on: April 06, 2010, 10:30:08 AM »
yes, the stereo useage is probably my favorite part of the entire thing.
[Fri 19:34]<nectarsis> been wanting to try that one for awhile now Ope
[Fri 19:33]<Opethian> l;ol huge dong

I'm a max level Forum Warrior.  I'm immortal.
If you're not ready to defend your claims, don't post em.

hcf

  • Jr. Member
  • **
  • Posts: 93
Re: It's MML time.
« Reply #62 on: April 06, 2010, 10:49:17 PM »
hcf. Going by what you posted earlier, yeah, you do need to change some stuff. the ^ is actually a tie, so something like c4^16 needs to be changed to c4&c16. note that you have to put the note name in for squirrel. I didn't see any ~'s, so I have no idea what they mean...possibly a slur?

It works!! Thank you TheOldMan, your suggestion is correct!!

In order that everybody can use this method, I am going to write an explanation FOR DUMBS, explaining my experience and which is the best method that I have found (without musical knowledge): I pick a MID file from internet, and I use the program TinyMM. This program produces a MML file.

We must do two things with this MML file: the first thing is copy the information of every channel, and paste that information in the channels of a working MML sample (for example, I used Cathedral.mml). The rest of the channels of Cathedral.mml must be empty. I used Cathedral.mml and not Skeleton.mml because Cathedral already has the information of the headers of the channels. In this headers info, you must change the Waveform (aka "musical instrument") which is the number following the "@" symbol, and in channel 0 you must change the Tempo (the number following the "T") which is the speed of the song.

Finally, as TheOldMan said, you must change every ^ symbol in this way: convert b4^8 in b4&b8 (is something like repeating a note). This is the key!!! My previous tests were not well synchronized because Squirrel ignored the notes after the ^ symbol. When these notes are not ignored, the musci plays well :)

Well, after all my tests I only can say... thank you, Arkhan and TheOldMan! Now I am going to test the power of Squirrel ;)

touko

  • Hero Member
  • *****
  • Posts: 953
Re: It's MML time.
« Reply #63 on: April 07, 2010, 12:44:46 AM »
Cool hcf, this was an easy way to make mml ..

A noob like me in music says :clap: to you ..

Eh arkhan, it's normal that sngInit.c is not present in your squirrel2.0 archive ???  :-"

This 2.0 version, seems to be very clean  :clap:
« Last Edit: April 07, 2010, 12:52:01 AM by touko »

Arkhan

  • Hero Member
  • *****
  • Posts: 14142
  • Fuck Elmer.
    • Incessant Negativity Software
Re: It's MML time.
« Reply #64 on: April 07, 2010, 01:52:02 AM »
Good good


What a tie means is for example:

C4&C8 will play a note that is as long as a C4 and C8 note, but instead of retriggering the note, it blends it together into one long note.

so instead of hearing "doooo doo" you just hear "doooooo"

:)
[Fri 19:34]<nectarsis> been wanting to try that one for awhile now Ope
[Fri 19:33]<Opethian> l;ol huge dong

I'm a max level Forum Warrior.  I'm immortal.
If you're not ready to defend your claims, don't post em.

hcf

  • Jr. Member
  • **
  • Posts: 93
Re: It's MML time.
« Reply #65 on: April 07, 2010, 02:52:34 AM »
Quote
so instead of hearing "doooo doo" you just hear "doooooo"

LOL!! I have counted the number of "o" letters, and I understand exactly what you mean... I think that it is a perfect explanation  :D

Quote
Cool hcf, this was an easy way to make mml ..

Yes, this is the reason why I tried to search a method to convert MID to MML: people without the capabilities to compose music (like me) can now use the amazing Squirrel tool to insert PSG music in our games, because internet is full of MID files.

Arkhan, now I will suggest a task for Squirrel 3.0, hehehe :mrgreen:  The manual that you made is impressive, but maybe you can write another little README file, explaining the basic functions of your library. For example, I think that I understand functions like psgOn(), psgInit(), sngInit() or psgPlay( ), but maybe you can explain what is the purpose of the rest of the functions, what is the correct way to stop music ( I think that it's psgAllStop ), how to use a list of several songs, how to loop a song...

In fact, I think that I know how to do almost all those things (I have tested your library a lot in these days, hehehe) but I think that it will be positive for everybody to have that explanation (again, "for dumbs") written by you, the legitimate author of the library.  :)

TheOldMan

  • Hero Member
  • *****
  • Posts: 958
Re: It's MML time.
« Reply #66 on: April 07, 2010, 03:23:18 AM »
tuoko:
"Eh arkhan, it's normal that sngInit.c is not present in your squirrel2.0 archive ???  "

yes. mml2pce generates that as it compiles the mml. It has all the low-level calls to the psg-bios to make the mml play. Note that snginit.c is a generic filename. If you have several mml files in one place, sngInit.c reflects the last one compiled.

hcf:
"maybe you can write another little README file, explaining the basic functions of your library"..
No Need. The actual library (in sound subdirectory, I think) is just HuC friendly calls to the psg-bios; a nice easy way to do it in Huc. So, if you can find the devlo docs, all the calls in the psg-bios section should apply. (Well, The name changed for one of them, psgMute I think - it made more sense)

And for those of you who are really interested:
"Squirrel" is really not a library, per se. The library portion is in the sound directory, and they are all very short assembler functions: basically, they pull the parameters off the huc stack, stick them where they belong, and call the psg-bios function. It's quite boring and easy to follow if you even sorta know how assembler and the psg-bios stuff works. It's not anything you can't do in assembler yourself.
The compiler (mml2pce) basically converts the mml to the bytecodes expected bythe psg-bios. That's a bit more complicated, but with docs in hand, you can see how it gets done. That is, what gets generated for what mml. And if you are real adventurous, you -can- edit the assembly produced, and do some things the compiler can't (like play an alternating sequence of really short notes in sync - you have to adjust the times for odd 128th notes to keep sync).

As for squirrel 3.0, that's a different subject. Let's just say that that release is coming, and should bring music to everyone - not just those with cd players. The more it gets worked on, the more Arkhan understands what's going on in the psg-bios, so....

Personally, I'm working on an explanation of exactly how all the envelopes work, and some of the 'odd' things the psg-bios does. Hopefully, Arkhan will edit it down, and include it in the next release.

(for those who are interested in wierd things, here's a pet project that's one the back burner for now:
Take a voice sample, real short. Convert it to 5-bits, and build a sequence of wave forms from it. Then, create a drum that just plays those waves, in order. Make an MML that plays that drum, and let me know how it turns out....)


TheOldMan

  • Hero Member
  • *****
  • Posts: 958
Re: It's MML time.
« Reply #67 on: April 07, 2010, 04:30:56 AM »
Hcf: Sorry, I forgot in the earlier post. If you add a name to the channel
(ie, .channel 3 alt) you can do a jump to that label with /alt/. That lets you repeat a channel.
You probably have to do this for all the channels to loop a song, though. At that point its just
as easy to put a Dal Segno at the end of each channel. ('}'). Without an opening { that will cause the channel to repeat forever :-)
Sorry, there's no easy way to keep a song playing forever, though you might want to look into the psgMstat function to see when a song ends, and just re-start it with psgPlay.

As for playing multiple songs....
Make a .TRACK. for each song. Then you can play each song by changing the value passed to psgPlay():  psgPlay(0) plays the first song, psgPlay(1) plays the second, etc.
And before you ask, you need to set up the channels for each song seperately (.TRACK tells the compiler a new track is starting), but you can re-use macros across songs :-)

If you have a good idea on how to mark a section of a channel with a label, let us know. That's one of the weaker points of squirrel right now - no easy/good way to use the jump function.
« Last Edit: April 07, 2010, 04:33:14 AM by TheOldMan »

Arkhan

  • Hero Member
  • *****
  • Posts: 14142
  • Fuck Elmer.
    • Incessant Negativity Software
Re: It's MML time.
« Reply #68 on: April 07, 2010, 05:14:43 AM »
Arkhan, now I will suggest a task for Squirrel 3.0, hehehe :mrgreen:  The manual that you made is impressive, but maybe you can write another little README file, explaining the basic functions of your library. For example, I think that I understand functions like psgOn(), psgInit(), sngInit() or psgPlay( ), but maybe you can explain what is the purpose of the rest of the functions, what is the correct way to stop music ( I think that it's psgAllStop ), how to use a list of several songs, how to loop a song...

In fact, I think that I know how to do almost all those things (I have tested your library a lot in these days, hehehe) but I think that it will be positive for everybody to have that explanation (again, "for dumbs") written by you, the legitimate author of the library.  :)

Like the old man said, Squirrel is just using the stuff built into the system already.  The HuC stuff is just wrapper functions for the assembly bios calls.... so what you are getting is something very, very similar to what developers were using back in the day.

but I do understand that some people reading this just saw "wrapper functions for the assembly bios calls" and went "O_O WHAT?"

I will definitely write another little readme file for how the library functions work.   If you manage to get your hands on Develo books, the problem is, well, they are Japanese so.... its not so easy to read.

It may take a bit of time, since I have school stuff going on right now, and stuff for the upcoming show in a month, but I will definitely make a readme with translations of the different functions.   It will be good for both programmers, and for "dumbs" , as you put it.  :).  I guess I never really considered doing that, since the setup included in the zip file is setup to compile & play!


to everyone reading who's using, or is planning to use squirrel, I encourage you to head over to www.aetherbyte.com/forums     There is an MML section, and it would be a pretty good place for everyone to collectively discuss everything, and share what they have been working on.


and, yeah, the enveloping description could probably use some work, and some examples.  Luckily the 16 included envelopes are enough to do alot.
[Fri 19:34]<nectarsis> been wanting to try that one for awhile now Ope
[Fri 19:33]<Opethian> l;ol huge dong

I'm a max level Forum Warrior.  I'm immortal.
If you're not ready to defend your claims, don't post em.

touko

  • Hero Member
  • *****
  • Posts: 953
Re: It's MML time.
« Reply #69 on: April 07, 2010, 08:00:53 AM »

yes. mml2pce generates that as it compiles the mml. It has all the low-level calls to the psg-bios to make the mml play. Note that snginit.c is a generic filename. If you have several mml files in one place, sngInit.c reflects the last one compiled.


Ok thanks for explanation  :wink:

Charles MacDonald

  • Newbie
  • *
  • Posts: 14
Re: It's MML time.
« Reply #70 on: April 09, 2010, 01:39:52 PM »
(for those who are interested in wierd things, here's a pet project that's one the back burner for now:
Take a voice sample, real short. Convert it to 5-bits, and build a sequence of wave forms from it. Then, create a drum that just plays those waves, in order. Make an MML that plays that drum, and let me know how it turns out....)

This is a super cool idea, I think the problem people have had in the past when it comes to implementing this concept is the timing.

For example, assume channel 1 has 32 bytes of a sample loaded, and channel 2 has 32 bytes of a sample loaded. Both channels have their various settings made (panning, frequency, etc.) so all that has to happen next is a key-on.

1. Select channel 1. Write $9F to $0804. Channel 1 starts playing
2. Select channel 2. Wait for Channel 1 to stop (!). Write $9F to $0804 at that exact instant. Channel 2 picks up where channel 1 left off.

So the tricky part is knowing when to turn on channel #2 at precisely the right moment so the sample playback continues uninterrupted. And you'd also have to key-off channel #1 before it repeats the sample.

Because there is no synching mechanism to wave playback, it depends on having cycle accurate delays from the key-on of one channel to the key-on of another. The timer interrupt would introduce jitter due to the interrupt latency, so that's kinda out of the question. So it seems like the CPU would get tied up waiting during playback.

The other issue is that it isn't clear if the waveform index stays reset until key-on, or if it cycles continuously even when the channel is off - you'd never hear the difference, I think. I don't believe this behavior has been proven true or false, so it's all up in the air.

I think these complexities are why the PSG has DDA mode to make samples easy. Definitely not crapping on your idea though, it's a good one. Because others have kicked it around in the past I wanted to point out where people have gotten stuck. Maybe these limitations can be beaten! :D

Completely unrelated:

Perhaps somebody (not Aetherbyte, you guys have done enough!) could make a little tutorial about how to use the BIOS PSG library in general, and then give an example about doing that with the MML output from Squirrel. That way people who are approaching this from a game-programming POV would have an idea of how to have (say) multiple songs in a project and how to play one, stop one, etc. It's all very basic but just what the newbies need to enable their inner maestro.

The develo docs are perfectly good, but sort of dense for people unfamiliar with them. :D If nobody steps up to the plate I might do this from an assembly perspective. Partially because I want to get the hang of adding music to my own projects, and it would be nice to help others out.

TheOldMan

  • Hero Member
  • *****
  • Posts: 958
Re: It's MML time.
« Reply #71 on: April 09, 2010, 02:10:22 PM »
Actually, charlie, the timing wouldn't be as bad as you think. I understand the transition isn't going to be seamless; that's not a problem, really. I don't think one vsync more or less will be all that noticeable.
I'm not actually talking about using two channels or trying to sync them in anyway.
BUT, the psg-bios player is pretty good about handling things in one vsync. So, if you take an appropriate
sample wave form (I used 22KH ) and convert it to 5-bit waveforms, the psg-player can re-load the wave form every vsync. Assuming the frequency is correct (so the wave plays once every vsync), it should be
possible to play a wave, load the next and play it, etc. Not in real time, of course. That would require hooking the timer and using it to control things.
Granted, it's not going to be high fidelity. It's going to be a long search for the right frequency combinations. And I'm sure there are a million other things that *could* go wrong. But in the sample run I did (really quickly thrown together, mind you) using about 40 waveforms, I got a recognizeable representation of the original sound.
Maybe I'll try a voice sample next... Anyway, it's just one of those strange things that kinda popped into my head while I was doing something with squirrel. I wondered how fast the psg-player could swap waveforms, and one thing led to another.

Charles MacDonald

  • Newbie
  • *
  • Posts: 14
Re: It's MML time.
« Reply #72 on: April 09, 2010, 02:21:11 PM »
Granted, it's not going to be high fidelity. It's going to be a long search for the right frequency combinations. And I'm sure there are a million other things that *could* go wrong. But in the sample run I did (really quickly thrown together, mind you) using about 40 waveforms, I got a recognizeable representation of the original sound.
Maybe I'll try a voice sample next... Anyway, it's just one of those strange things that kinda popped into my head while I was doing something with squirrel. I wondered how fast the psg-player could swap waveforms, and one thing led to another.

Well that's all that matters - if it sounds decent, I'd say you solved the problem!

Arkhan

  • Hero Member
  • *****
  • Posts: 14142
  • Fuck Elmer.
    • Incessant Negativity Software
Re: It's MML time.
« Reply #73 on: April 09, 2010, 02:43:20 PM »

Completely unrelated:

Perhaps somebody (not Aetherbyte, you guys have done enough!) could make a little tutorial about how to use the BIOS PSG library in general, and then give an example about doing that with the MML output from Squirrel. That way people who are approaching this from a game-programming POV would have an idea of how to have (say) multiple songs in a project and how to play one, stop one, etc. It's all very basic but just what the newbies need to enable their inner maestro.

The develo docs are perfectly good, but sort of dense for people unfamiliar with them. :D If nobody steps up to the plate I might do this from an assembly perspective. Partially because I want to get the hang of adding music to my own projects, and it would be nice to help others out.


That could be arranged pretty easy from my POV.   I have like, 6 or 7 chip tunes I could stream together into..... hey wait we did this for Insanity! :D

duh

Yeah its really easy!  I can whip up a tutorial using the examples in Squirrel already, and have a file where you can put say 5 songs in one .mml file, convert it all, include the data as normal, and I will show you how to switch songs, etc.

that is, unless OldMan beats me to it!

If you want to try figuring it out before I get to it, you just include a second .TRACK complete with channels  0-6.    put as many as you want, each track is a new song! ... then psgPlay(0), psgPlay(1), etc. etc. for each song in the file.

but, I will definitely whip up a document explaining the player functions for use with HuC.  :)
[Fri 19:34]<nectarsis> been wanting to try that one for awhile now Ope
[Fri 19:33]<Opethian> l;ol huge dong

I'm a max level Forum Warrior.  I'm immortal.
If you're not ready to defend your claims, don't post em.

TheOldMan

  • Hero Member
  • *****
  • Posts: 958
Re: It's MML time.
« Reply #74 on: April 10, 2010, 01:50:24 AM »
"Well that's all that matters - if it sounds decent, I'd say you solved the problem!"

Uhh.. not really It's recognizeable, not decent. You can tell it's some kind of hi-hat cymbal, but other than that ...?

I thought about it a lot after I posted that, and here's what I came up with:
take a wave sampled at 4KHz, 8 bit, mono. Something around 1/4 sec long. Frequency shift it up 2 octaves. Dump it as a raw data file, and convert the bytes to 5-bit samples.
From there, chunk them into 32 byte waveforms. And play that back.

Assuming I used a voice sample, I have 2 questions: 1) Could you tell it was a voice? A Human voice? and 2) Could you make out what it was saying ?

This is more acedemic than practical, to start with. I recognize the even running the mml player at its highest rate, and putting the waves in a sub-track is at best going to give a playback rate of less than 1KHz. Not to mention that you would need about 300 waveforms to do 1 second of sound. But I can't help wondering if even that low quality sound with a shorter player back time wouldn't give up a really nice booming tom-tom drum, or a crash cymbal that actually had a nice tone, and not just noise....