PCEngineFans.com - The PC Engine and TurboGrafx-16 Community Forum
Tech and Homebrew => Turbo/PCE Game/Tool Development => Topic started by: TailChao on November 08, 2014, 01:51:35 AM
-
Hi all,
I've decided to release the sound tools I've been working on for the PCE. They're based upon the environment I created for the Lynx which uses the SASS (http://www.tailchao.com/Audio/SASS.php) language to write music and sound effect scripts.
This has been written for the WLA-DX assembler, and uses the MCGenjin memory mapper (so Mednafen and hardware only). Sorry, no HuC or cc65 environment support. All of the source is included with each version of the driver if you'd like to add your own cool features or port it to something else.
Here's some of the neato things you get with HuSound:
-Included audition/test ROM with waveform and mode watcher
-Included demo instrument set
-Minimal bank alignment restrictions for music/sfx data
-Instruments and sound effects can switch among waveform, noise, and PCM mode on a single channel.
-Stereo Panning for music, sound effects, and samples
-6.992KHz PCM Playback on any channel
-Multichannel sound effects
-Dispatch of multiple sound effects per frame
-Configurable priority system among music, sound effects, and samples
-Attenuation support for music (can be used for fade-ins, fade-outs, etc)
You can download the newest version (v1.3cz) here (http://www.tailchao.com/Audio/index.php#HuSound).
I've also uploaded some test footage + covers to give a better idea of what the driver can do.
The ROM and SASS Scripts used for these covers are available here (http://tailchao.com/Audio/HuSound/SecretSASS_2015-11-10.zip).
Have fun!
-
(http://junk.tg-16.com/images/hany_in_the_sky.html)
I have no skills, but I know this is a good thing.
-
Great documentation too, Thanks!
-
Well, the Phantasy Star II tune made me piss myself.
-
Well, the Phantasy Star II tune made me piss myself.
Yes! PSII city music! I too am in need of a diaper change after hearing this on the PCE sound hardware! :)
-
Bitch, it's the save-data screen music, not the city music.
-
So, is this engine compatible with channels being dynamically pulled out for sound effect duty?
-
Bitch, it's the save-data screen music, not the city music.
Oh yea, you're right, you whore! It's been years since I've fired up PSII. Either way, it sounds awesome on the PCE :)
-
This looks great. So, what's the memory / raster time usage?
-
Thanks for the feedback.
So, is this engine compatible with channels being dynamically pulled out for sound effect duty?
Yes, each channel of a music track (if playing) has an assigned priority. All sound effects also have priorities which are used during their dispatch to see if they can "borrow" a channel from the music track if it is in use.
This looks great. So, what's the memory / raster time usage?
40 Bytes ZeroPage and 894 Bytes of RAM. Kind of fat, but I added so much RAM on the cartridge that this is a bit moot. The depth of the loop / call stacks used in the driver can be adjusted from their default of depth four as well which could easily get you a hundred or so bytes off. Same goes for the sound effect dispatch queue (default depth is eight).
Performance is (really really) variable because of the macro instrument setup. The first two attachments show driver time in "average" and "bad" states. RED indicates audio register writes, BLUE is VRAM transfers (ignore), and PINK is the driver update tick. This is something I'd like to improve in the future. CALLs and BREAKs are super expensive since there are no alignment restrictions on music, instruments, or sound effects.
The next two attachments show PCM IRQ time (in pink) for one and two PCM channels in use respectively. While six is supported, playing that many samples at once will definitely mess up any HBL rasters you may be using.
-
These sound great! How practical is this for use ingame, would you say it's still CPU intensive enough so that it couldn't be used for full fledged games? I assume the overall goal is to make this practical for full homebrew game projects? That would, ofcoarse be sweet, & it'll be nice to have different options for dev's in the future for music making.
-
These sound great! How practical is this for use ingame, would you say it's still CPU intensive enough so that it couldn't be used for full fledged games? I assume the overall goal is to make this practical for full homebrew game projects? That would, ofcoarse be sweet, & it'll be nice to have different options for dev's in the future for music making.
The driver was written for use in a game, so it should be fine. The big performance hit comes from having no alignment restrictions, so the driver has to do two levels of banking math (both 8KB/MPR and 256KB/MCGenjin). But the convenience you get out of this is huge, so I'm willing to dump the cycles.
Of course, if you're doing heavy effects (more SASS instructions per frame = more data to fetch), you'll be using more of the HuC6280's time. Running 3+ PCM streams and decoding complex music / sound effects might be doable in something mellow like Bonk, but you'd have to scale things back for a game which needs more cycles to do its own calculations.
Since the source is available, you are free to chop off parts you don't want or add things that you'd like. For example the standard version of my Lynx sound tools doesn't support music fade outs, but the modified one which I'm using in a new game does.
I think the only challenge here is that everything was written for MCGenjin, which has a bit of a learning curve if you're unfamiliar with it. This can obviously be removed, but it is quite cool to use the same card in a PCE and TG16 with no mods or switches.
-
What do you think would be the most difficult aspect of altering this engine for use without the MCGenjin mapper? I ask because Arkhan already has a homebrew board he's shipping with Atlantean, and there is now a Turbo EverDrive that makes playing homebrew and hack titles much easier.
-
What do you think would be the most difficult aspect of altering this engine for use without the MCGenjin mapper? I ask because Arkhan already has a homebrew board he's shipping with Atlantean, and there is now a Turbo EverDrive that makes playing homebrew and hack titles much easier.
It is really not that difficult to remove the MCGenjin stuff. What is difficult is adapting the driver to HuC, which I believe Arkhan and friends are using.
-
What do you think would be the most difficult aspect of altering this engine for use without the MCGenjin mapper? I ask because Arkhan already has a homebrew board he's shipping with Atlantean, and there is now a Turbo EverDrive that makes playing homebrew and hack titles much easier.
It is really not that difficult to remove the MCGenjin stuff. What is difficult is adapting the driver to HuC, which I believe Arkhan and friends are using.
Most of Atlantean is inline assembly, and most of Squirrel is wrapper code to call into the asm stuff. :)
-
Most of Atlantean is inline assembly, and most of Squirrel is wrapper code to call into the asm stuff. :)
Which is fine. My point was that WLA-DX is very different syntactically from HuC, inline ASM or not. This would complicate moving HuSound to the HuC environment.
(Edit: Just trying to be clear on what is and is not with the driver, no offense to you or your game).
-
Oh, yeah. None taken. Taking offense is for pussies. This isn't a Neo Geo forum, hahahahahrgthghbnoidj.
What made you pick WLA-DX anyway?
-
TailChao, whats that new Lynx game you are working on all about?. Since you already played tribute to Zonk, with Zaku, could the new one be a Bonk type game for the Lynx :pray:!?
Or did i hear something about a Metal Gear Solid type game :)...
A Zaku port to the PCE would be incredible too!!! Ever tought about doing a PCE game?
-
Oh, yeah. None taken. Taking offense is for pussies. This isn't a Neo Geo forum, hahahahahrgthghbnoidj.
MAX 330 MEGA PRO-ANGST SPEC
What made you pick WLA-DX anyway?
I was working on a title for the Super Nintendo for about two years after Zaku shipped and started using WLA-DX then.
The game was canned but I "got used to" the assembler and decided to revisit it when developing the MCGenjin. I don't necessarily agree with everything WLA-DX does (for example, including large files which span over several banks is more cryptic than it should be), but it has some good ideas. Definable width banks are pretty cool.
It also forced me to write all my own libraries for reading the controllers, talking to the VDC, etc, which is a good way to learn about a platform.
TailChao, whats that new Lynx game you are working on all about?. Since you already played tribute to Zonk, with Zaku, could the new one be a Bonk type game for the Lynx :pray:!?
Or did i hear something about a Metal Gear Solid type game :)...
All I can say is that it's an action game, 2MB large, and some things from Zaku will make an appearance.
There is no hidden METAL GEAR?! behind my avatar :wink: .
(Seriously though- I'll announce it when it is done. Not trying to be a jerk and dangle a carrot, since I've wanted to release a trailer for the past two years. But it is much easier to manage this way).
A Zaku port to the PCE would be incredible too!!! Ever tought about doing a PCE game?
I have thought about it quite a bit (hence making an audio driver), and have a few designs that would work on the platform. The HuListen program in this audio suite was made from ripped apart game engine tests anyway.
Zaku will stay exclusive to the Lynx. Because of the time these games take to develop, I would rather do something very different each time, even if working on a sequel.
However, if you'd like to throw $250,000 (US) and a two year development contract at me and my friends, I'd be more than happy to deliver the best PC-FX menus game ever.
-
Really fantastic videos and discoveries!
Thank you for tinkering with our beloved PCE/Turbob. I hope we'll all get to play one of your creations some day soon!
-
The game was canned but I "got used to" the assembler and decided to revisit it when developing the MCGenjin. I don't necessarily agree with everything WLA-DX does (for example, including large files which span over several banks is more cryptic than it should be), but it has some good ideas. Definable width banks are pretty cool.
It also forced me to write all my own libraries for reading the controllers, talking to the VDC, etc, which is a good way to learn about a platform.
The only assembler I've ever gotten used to enough to not want to use an alternative, is tniASM for MSX.
I definitely don't have any attachment to PCEASM or anything.
Zaku will stay exclusive to the Lynx. Because of the time these games take to develop, I would rather do something very different each time, even if working on a sequel.
However, if you'd like to throw $250,000 (US) and a two year development contract at me and my friends, I'd be more than happy to deliver the best PC-FX menus game ever.
\o/
yeahhaaaaaaaaaa
Have you thought about making any games for PC Engine?
-
All I can say is that it's an action game, 2MB large, and some things from Zaku will make an appearance.
There is no hidden METAL GEAR?! behind my avatar :wink: .
(Seriously though- I'll announce it when it is done. Not trying to be a jerk and dangle a carrot, since I've wanted to release a trailer for the past two years. But it is much easier to manage this way).
LOL!, you dont sound ike a jerk at all, your position is understandable. And anyways, anyone who can make a game of the audio-visual quality, gameplay and charm of Zaku, for a super cool system like the Lynx, can act like a jerk whenever he wants, in my book :).
-
Hi all,
I've decided to release the sound tools I've been working on for the PCE. They're based upon the environment I created for the Lynx which uses the SASS (http://www.tailchao.com/Software/SASS.php) language to write music and sound effect scripts.
This has been written for the WLA-DX assembler, and uses the MCGenjin memory mapper (so Mednafen and hardware only). Sorry, no HuC or cc65 environment support. All of the source is included with each version of the driver if you'd like to add your own cool features or port it to something else.
Here's some of the neato things you get with HuSound:
-Included audition/test ROM with waveform and mode watcher:
(http://www.tailchao.com/Software/HuSound/HuSound.gif)
-Included demo instrument set
-Minimal bank alignment restrictions for music/sfx data
-Instruments and sound effects can switch among waveform, noise, and PCM mode on a single channel.
-Stereo Panning for music, sound effects, and samples
-6.992KHz PCM Playback on any channel
-Multichannel sound effects
-Dispatch of multiple sound effects per frame
-Configurable priority system among music, sound effects, and samples
You can download the newest version (v1.1c) here (http://www.tailchao.com/Software/HuSound/index.php).
I've also uploaded some feature test footage and covers to give a better idea of what the driver can do.
Have fun!
That Phantasy Star cover is awesome! I love the fact that it adds that PCE sound to it.
-
Woah! Long time no update!
HuSound v1.2c is now available here (http://tailchao.com/Audio/index.php#HuSound).
*You can now control the attenuation of music tracks (for fade ins, fade outs, whatever) by calling HuMusic_ReqAtten with your desired music attenuation in A (0 = loudest, 15 = silent).
*Sound effects will no longer dispatch over channels which contain idle / resting music which is at a higher priority.
-
HuSound v1.2c is now available here (http://tailchao.com/Software/HuSound/index.php).
Excellent, I hadn't been aware of this! :)
SASS is much closer to what I'm used to than MML ... being based on SPL by Epyx (a Western developer) vs MML (more common with the Japanese developers). The 2 regions really do think a bit differently.
May I ask what license this is released under? I can't find any licensing or copyright information in a quick "grep" search of the files. Am I missing it somewhere?
I do hope that you'll allow it's use under something like the MIT, BSD, Apache or zlib licenses.
You're not alone in being a bit lax about deciding on licenses ... I've released a couple of things under the Boost license, but still haven't decided what license the PCE/PC-FX tool work will come under (MIT/BSD/Apache/zlib).
-
Excellent, I hadn't been aware of this! :)
SASS is much closer to what I'm used to than MML ... being based on SPL by Epyx (a Western developer) vs MML (more common with the Japanese developers). The 2 regions really do think a bit differently.
Yeah, that's basically the major reason I started writing all these different sound tools.
May I ask what license this is released under? I can't find any licensing or copyright information in a quick "grep" search of the files. Am I missing it somewhere?
I'm not sure what the proper term is, but as with most tools I released it's a "do whatever you like with it, just don't blame me if you burn down your house" license (there should be a little quip in the programmer's manual). So basically you're free to take the driver + compiler and modify them, include them with other things, etc.
Edit:
You're not alone in being a bit lax about deciding on licenses ... I've released a couple of things under the Boost license, but still haven't decided what license the PCE/PC-FX tool work will come under (MIT/BSD/Apache/zlib).
The way I look at it, the only really valuable thing for these old platforms is the game software and IPs. So I just give the tools away since there's no good reason to profit from them or inconvenience anyone else with licensing.
-
The way I look at it, the only really valuable thing for these old platforms is the game software and IPs. So I just give the tools away since there's no good reason to profit from them or inconvenience anyone else with licensing.
I totally agree ... which is why I want to give away the work that I'm doing on improving the toolset, and put it on github for anyone that wants it.
But in order for someone (guess who) to legally incorporate your player in a game, or to modify your code so that it assembles with CA65, or to convert it over to the PC-FX, or to distribute your tools on github ... you need to put your intent in a legal form.
Since you automatically own the copyright on everything that you've written, licensing is a real legal issue even if there's no money, or attribution, or even any future discussion with you.
You're working at Google now ... if you haven't had the talk on that yet, then I'm sure that it's going to get raised at some point.
The closest thing that I've seen to a legal version of "giving it all away" is the Boost License. The Zlib license is a very close 2nd, but a bit wordier. I personally prefer the Boost License ... less legal rubbish at the top off the source file.
That's basically a "Do whatever you like with it, and I don't need a credit in your documentation." kind of license.
It's also a legal disclaimer which stops people from suing you if their dog hears a particularly awful chiptune and runs under a bus. Trust me on this ... you need that legal disclaimer in this day and age.
It would be as simple as adding the following simple notice to every file ...
Copyright Osman Celimli 2014-2015.
Distributed under the Boost Software License, Version 1.0.
(See accompanying file LICENSE_1_0.txt or copy at
http://www.boost.org/LICENSE_1_0.txt)
It would be nice to also add a link back to your website. Even if your site goes away in the future, there will probably be a copy in the "Way Back Machine" archives.
You really should be the one to do this (especially since you've got the only copy of the PDF source) ... and then release it on your website.
That's how this sort of thing is legally done these days. (Darned lawyers!)
If you can't be bothered to do that yourself ... then I can add those lines to the source files on your behalf ... if you post here that that is your wish, and that those are the correct dates and the license that you wish to use. (But you really should be the one to do it ... it's one of the responsibilities of an author).
For a comparison of your licensing options, you can look at sites like ...
http://choosealicense.com/licenses/ or
http://en.wikipedia.org/wiki/Comparison_of_free_and_open-source_software_licenses
(EDIT)
BTW ... a similar discussion also applies to your layout files for the CD Stupid Card if you want the community here to be able to run off a production batch of cards at some point.
-
This probably isn't the place for this, but I sure would like a music composer program for PCE that would allow some sort of external sync via MIDI or gate signals. How hard would it be to bridge the gap between this project and the one I'm describing?
-
...
But in order for someone (guess who) to legally incorporate your player in a game, or to modify your code so that it assembles with CA65, or to convert it over to the PC-FX, or to distribute your tools on github ... you need to put your intent in a legal form.
Since you automatically own the copyright on everything that you've written, licensing is a real legal issue even if there's no money, or attribution, or even any future discussion with you.
You're working at Google now ... if you haven't had the talk on that yet, then I'm sure that it's going to get raised at some point.
...
(EDIT)
BTW ... a similar discussion also applies to your layout files for the CD Stupid Card if you want the community here to be able to run off a production batch of cards at some point.
Edit:
I originally wrote a few nonsequitor sentences here then realized I'm not in any state to think about legal messes. Let's discuss options further via PM if you want to include the driver in any of your work. In the mean time, I suggest playing with it to see if it actually fits your needs.
I do somewhat miss when I started development work in the early 2000s and everything was like this (http://www.wtfpl.net/). Stuff like Magic Kit doesn't even have mention of a license. Whatever.
This probably isn't the place for this, but I sure would like a music composer program for PCE that would allow some sort of external sync via MIDI or gate signals. How hard would it be to bridge the gap between this project and the one I'm describing?
Actually this is quite a fine place for it.
To answer your question, modifying HuSound to support MIDI triggering is not such a big deal. Instruments and sound effects are the same internally, and music is just generated via a script instantiating instrument play requests with frequency offsets. This could be replaced with a MIDI decoder or whatever.
The challenge is more of a hardware one. If you want proper physical MIDI support you'd need a UART and some optoisolators on a(nother) special cartridge.
It's actually cheaper and easier just to use a $2 STM32 microcontroller and run a PCE-style soft synth on it, then add MIDI support there (which is another project I have on the way).
-
There is no reason why the PCE couldn't sync with a special cable in the controller port. Full MIDI would be nice but honestly just making it sync to a gate/trigger would be enough for me personally. That's now almost all my stuff works.
-
There is no reason why the PCE couldn't sync with a special cable in the controller port. Full MIDI would be nice but honestly just making it sync to a gate/trigger would be enough for me personally. That's now almost all my stuff works.
I don't think I fully understand your requirements, then.
Do you want just syncing to start / stop music and sound effects? Play individual notes?
-
With many old fashioned electronic instruments (either pre-MIDI or just belligerently non-MIDI stuff made this year) the tempo is kept by a 10V trigger. Notes are done on a 1V/octave scale.
This is the normal way instruments like the Doepfer A-100 comunicate. It's actually a lot more flexible than MIDI as demonstrated here:
https://m.youtube.com/watch?v=O8N1Pl0NI30
A click track, basically. Every time there is a click the sequence is re-aligned.
-
I originally wrote a few nonsequitor sentences here then realized I'm not in any state to think about legal messes. Let's discuss options further via PM if you want to include the driver in any of your work. In the mean time, I suggest playing with it to see if it actually fits your needs.
I'll PM you, and see if you want to backtrack on the WTFPL license ... which is, of course, exactly why it is important to bring this stuff up in any development that uses "free" software!
I do somewhat miss when I started development work in the early 2000s and everything was like this (http://www.wtfpl.net/).
The Boost License and the Zlib License are the grown-up versions of the WTFPL license ... they basically add the protection that anyone using the source not sue the author ... kind of important in a world where you can get sued for serving a cup of coffee that's "too hot".
Stuff like Magic Kit doesn't even have mention of a license. Whatever.
Simpler times, I'm afraid.
I don't think that I was ever asked to put a copyright notice in my early games' source. It was all proprietary tech where nobody else ever saw the source.
GNU/FSF changed the world, first by creating the idea of "open-source" that anyone could use ... then by creating a legal framework in which it's openness could be protected ... and then by suing companies that just took the source without complying with the license.
It doesn't mean that theirs is the only way ... lots of alternatives have emerged because people found GNU/FSF to be too dogmatic and restrictive.
But they did make everyone pay attention to the legalities, and not just "assume".
I can't say that I'm happy with all the changes in the world over my lifetime ... but I have to live with those changes, whatever my personal feelings are.
I like to release my stuff under a very permissive license ... but some people can't stand that someone out there might ever make any money when using their stuff, and so want to use something like the GPL or LGPL.
If you look around at open source projects that real companies pay people to work on ... there's a lot less GPL/LGPL these days, and a rise in less restrictive Mozilla or Apache use.
-
With many old fashioned electronic instruments (either pre-MIDI or just belligerently non-MIDI stuff made this year) the tempo is kept by a 10V trigger. Notes are done on a 1V/octave scale.
This is the normal way instruments like the Doepfer A-100 comunicate. It's actually a lot more flexible than MIDI as demonstrated here:
https://m.youtube.com/watch?v=O8N1Pl0NI30
A click track, basically. Every time there is a click the sequence is re-aligned.
Haha ... you make my want to plug in my Waldorf Pulse again!
One of my "side" interests is in doing a modernized Develo-board ... basically a USB microcontroller hooked up to the PCE's joypad port. I don't think that I have a spare serial port left on the board for MIDI, but there may be a spare A/D converter pin for a gate signal.
No timescale on that though ... too much software to do ... but the hardware is sitting in a box waiting!
-
I have Apple Logic for powerful MIDI stuff and I barely even use that. Analog tempo sync is the most important thing to me. With a voltage controlled sync a PCE could sing along with all my other gear and it would be fantastic.
-
I have Apple Logic for powerful MIDI stuff and I barely even use that. Analog tempo sync is the most important thing to me. With a voltage controlled sync a PCE could sing along with all my other gear and it would be fantastic.
I wondered if that was where you were going with this.
My analog-electronics days are far behind me, but that just sounds like a Schmitt Triggered gate going into one of the data bits on the PCE's joystick port. I'm sure that TailChao will have a better handle on it.
-
We had talked about making a MIDI interface of sorts awhillllllllllllle back. I'm not sure if CharlieMac ever got anywhere. From what I remember, doing the hardware part is not hard.
The sound engine that Squirrel was using at the time was perfect for live-playing, which is obviously what you would want out of an instrument you are actively touching.
really though, it's a bit of a wasted effort I'd say, as there would not be many users probably, and you can get the same kind of sounds out of a few of the VSTs floating around. One does 32-byte stuff like PCE.
It's basically a PCE/Konami SCC VST. You can draw the wave sample and control filters/envelopes.
I generally use that to mockup the tunes I write that end up in games.
EDIT: Also, MML is not too daunting. It's fairly 1:1 with sheet music. Most of the work can be cut by simply converting a MIDI to MML. It's a very fast, practical, streamlined way to generate music, especially on a system designed for it.
-
I'm sure it's not hard, but if I have to type anything I'm not doing it. It sounds lame, but ever since my music when fully hardware my productivity has skyrocketed. I'm not typing anymore ever.
-
I'm sure it's not hard, but if I have to type anything I'm not doing it. It sounds lame, but ever since my music when fully hardware my productivity has skyrocketed. I'm not typing anymore ever.
http://www.kvraudio.com/product/chip32_by_sam/details
You just use this in a DAW and drag the mouse around and press a key on your MIDI controller of choice and see if you like the noise you just drew.
I rock FruityLoops for all this crap. There's no typing. Just clicky stuff followed by keyboard-smacky-stuff.
-
With many old fashioned electronic instruments (either pre-MIDI or just belligerently non-MIDI stuff made this year) the tempo is kept by a 10V trigger. Notes are done on a 1V/octave scale.
This is the normal way instruments like the Doepfer A-100 comunicate. It's actually a lot more flexible than MIDI as demonstrated here:
https://m.youtube.com/watch?v=O8N1Pl0NI30
A click track, basically. Every time there is a click the sequence is re-aligned.
Huh, that's actually pretty cool.
I guess the easiest way would be to just make a little module that plugs into the controller port which can monitor the click track and then convert it to various scan codes. You'd have to poll it on the PCE side and then dispatch the appropriate instruments, but it would be cheaper than a custom cart.
In other news, I've released HuSound v1.2cz (http://tailchao.com/Audio/index.php#HuSound) which is the first proper open source release of HuSound, HuListen, and HSCC as per Elmer's request. After some thought, I've gone with the zlib license.
-
I kinda want to see a side-by-side write up of HuSound and Squirrel. I'm curious to know how they are similar and how they are different. What does one do that the other does not, and so on.
-
Squirrel is basically just an MML compiler that talks to the PSG BIOS.
so long story short, it is a 1:1ish translation of sheet music that compiles and plays on real hardware with minimal effort/overhead
-
Squirrel is basically just an MML compiler that talks to the PSG BIOS.
so long story short, it is a 1:1ish translation of sheet music that compiles and plays on real hardware with minimal effort/overhead
Didn't you guys write a compatible PSG player too, though? For hucard stuffs? I mean, not just a compiler.
-
I'm sure it's not hard, but if I have to type anything I'm not doing it. It sounds lame, but ever since my music when fully hardware my productivity has skyrocketed. I'm not typing anymore ever.
http://www.kvraudio.com/product/chip32_by_sam/details
You just use this in a DAW and drag the mouse around and press a key on your MIDI controller of choice and see if you like the noise you just drew.
I rock FruityLoops for all this crap. There's no typing. Just clicky stuff followed by keyboard-smacky-stuff.
Moving a mouse is way worse than a typing on a keyboard. Since this is a VST I'll give it a shot. I'll try mapping it to something.
I really hate "computer user" type actions while recording music. It's my creative kryptonite.
-
Didn't you guys write a compatible PSG player too, though? For hucard stuffs?
No, we modified the cd bios player and Huc stuff to get the player to work on a card (for testing).
-
I'm sure it's not hard, but if I have to type anything I'm not doing it. It sounds lame, but ever since my music when fully hardware my productivity has skyrocketed. I'm not typing anymore ever.
http://www.kvraudio.com/product/chip32_by_sam/details
You just use this in a DAW and drag the mouse around and press a key on your MIDI controller of choice and see if you like the noise you just drew.
I rock FruityLoops for all this crap. There's no typing. Just clicky stuff followed by keyboard-smacky-stuff.
Moving a mouse is way worse than a typing on a keyboard. Since this is a VST I'll give it a shot. I'll try mapping it to something.
I really hate "computer user" type actions while recording music. It's my creative kryptonite.
Oh, you only need to use the mouse for the VST for drawing your waveform. It all responds to MIDI though from what I remember. It's worth checking out, especially since it's all free!
and yeah, the HuCard version of the player is more or less the BIOS one. Why radically rewrite something that is already there, and working.
-
In other news, I've released HuSound v1.2cz (http://tailchao.com/Software/HuSound/index.php) which is the first proper open source release of HuSound, HuListen, and HSCC as per Elmer's request. After some thought, I've gone with the zlib license.
Thank you! :) Putting a license on it clarifies how people like me can use it ... and you've chosen a generous license that's perfect for library code.
I look forward to hearing your demo tunes played back on a PC-FX! :wink:
I kinda want to see a side-by-side write up of HuSound and Squirrel. I'm curious to know how they are similar and how they are different. What does one do that the other does not, and so on.
I just looked at Squirrel again ... and Arkhan seems to be marketing it as an MML compiler that produces files that are compatible with Hudson's built-in MML player that is built into the System Card.
Very sensibly, Squirrel also has it's own player that can be used on HuCards that obviously don't have the System Card available.
Back-in-the-day when the PCE came out, MML was big in Japan because of the MSX, and it made sense for Hudson to include a music driver in the CD BIOS in order to avoid every developer having to include their own music driver in the very limited 64KB of RAM that was available on the original PCE CD. MML must have seemed like the obvious choice.
MML still survives today, and there seem to be a few other MML compilers/players for the PCE ... such as XPMCK and HuSIC. Arkhan would be the guy to ask to tell you if/why Squirrel is better than those others.
But back in the 80's and 90's, MML wasn't the only way for musicians to write music for the sound chips that were built into home computers/consoles.
MML wasn't used much in the West (MSX flopped) ... the "big" thing for many years were "trackers" ... originally coming from the Amiga (which flopped in Japan). Like MML, "trackers" still exist, and it looks like Bonknuts has developed a "tracker" player for the PCE.
The 3rd option for developers were "custom" drivers, often specific to the musician/company that used them.
These were often created in order to provide more flexible/better environments (in their author's opinions) than the alternative "standard" environments.
HuSound comes out of that tradition, being based on Epyx's Sound Programming Language.
In practice ... these days, when musicians basically want to write their songs on real keyboards or using powerful PC-or-MAC-based DAWs ... Squirrel, Trackers and HuSound are all anachronisms.
The problem is more going to be in finding a musician that's willing to work with such primitive tech, more than whether one driver or the other has a "slight" technical advantage.
If you're a programmer or a musician, then just look at each and see which one feels more "comfortable" to you.
If you're a game-player, then I'd be very surprised if you'd every know the difference by the results that a good musician could produce with either.
-
The counter to this is that Squirrel, being MML, is easy for people who are borderline clueless to get up and running. It was made and designed to be accessible and practical.
Trackers are not really accessible, and really are not too intuitive.
They're clunky/archaic/annoying. They worked at the time because that's all you had. Now? They're a pain.
MML has a strong presence still in Japan today because of a game called Mabinogi.
Anyway, Squirrel comes with a sample setup where you can practically click a few things and get a song going.
For example, I don't recall NinjaSpirit injuring himself too hard doing this:
https://www.youtube.com/watch?v=fL7vjGyCSUE
The upside to using Squirrel over the other MML solutions is that those other ones are f*ck-all annoying to setup and use. I know how to do MML, and do it on a daily basis, and even I find them annoying.
Squirrel is far easier and more user friendly. It was made to be similar to Musica on MSX, which is still used in commercial stuff today.
AKA: You don't have to screw around with too many parameters and various blobs of bullshit.
Using the template file, the (hopefully helpful) manual that I wrote, and a little bit of experimenting, you can get songs going, fast.
Make a MIDI, convert it using the various utilities out there that do that.. copy paste... hit go.
done.
I am not saying HuSound is bad, though. I've honestly never used it, so I can't comment. I looked at it a little, shrugged, and said "f*ck it, I already have a working thing to do tunes.".
-
In practice ... these days, when musicians basically want to write their songs on real keyboards or using powerful PC-or-MAC-based DAWs ... Squirrel, Trackers and HuSound are all anachronisms.
The problem is more going to be in finding a musician that's willing to work with such primitive tech, more than whether one driver or the other has a "slight" technical advantage.
If you're a programmer or a musician, then just look at each and see which one feels more "comfortable" to you.
If you're a game-player, then I'd be very surprised if you'd every know the difference by the results that a good musician could produce with either.
Basically this. It's up to the composer and programmer to choose what is most comfortable for them and for the game. Much of what is "better" here is just preference.
The SASS language was made based upon my brother's and my own opinions regarding the shortcomings of both SPL and MML. So I made something that was easy for us to use.
The drivers are very different, though. HuSound uses a macro setup which lets you do completely chaotic things with instruments, but also generates large binaries and uses more memory.
-
TailChao, do you have any plans for a sane/easy way to convert from a MIDI into your format?
I think that's basically what makes Squirrel so powerful. You don't really have to actually do the MML. You just copy paste.
You only generally have to do MML if you're optimizing because your songs are 900 miles long.
-
TailChao, do you have any plans for a sane/easy way to convert from a MIDI into your format?
I think that's basically what makes Squirrel so powerful. You don't really have to actually do the MML. You just copy paste.
You only generally have to do MML if you're optimizing because your songs are 900 miles long.
There's a general MIDI to SASS converter I wrote available here (http://tailchao.com/Audio/index.php#MID2SASS).
As of version 1.1, it seems to be fairly compatible and will happily split MIDI channels into individual SASS tracks based upon detected activity. Of course, you still have to create your own instruments, set up looping, apply any effects, etc. But this is not a really big deal.
-
Cool. When I have some down time, I might give it a closer look. What kind of space/resource overhead does using it incur?
-
Cool. When I have some down time, I might give it a closer look. What kind of space/resource overhead does using it incur?
I put up some visuals regarding this back on the first page (http://www.pcenginefx.com/forums/index.php?topic=18008.msg379390#msg379390). The only difference between that version and the current one is that we're using ~7 bytes more RAM in v1.2cz.
There are two major things to keep in mind with this driver:
*The performance is extremely variable based upon activity. Playing PCM samples on all six channels will obviously eat your cycles.
*The RAM usage is high and music binaries are large, but I consider these moot because the sound tools are designed for use with the MCGenjin mapper. I think the Wario Land Boss cover was like 17KB or so.
-
Sort of off side topic, but I see 'tracker' and 'mml' (or script based stuff) as the interface in creating music - and not necessarily the music driver itself (though they can be write specifically this way). The last sound driver I wrote could run both formats: pattern based or command string based. I liked the idea of applying the strengths of command string structure to that of a simpler pattern/list format.
-
Unfortunately, a tracker is not a very musical interface, so I've always found it to be a clunky trainwreck to use. The more modern, functional equivalent to me, is a piano roll. I find that worlds more effective than a tracker's interface.
Since MML is a text representation of sheet music, it seems a bit more fluid.
-
Sounds like Squirrel is going to be easier for a n00b to get up and running, but HuSound might be a little more powerful/robust in terms of raw capabilities, if you can spare the memory and CPU cycles for it.
-
Sort of off side topic, but I see 'tracker' and 'mml' (or script based stuff) as the interface in creating music - and not necessarily the music driver itself (though they can be write specifically this way).
That's a very good point ... the musician's workflow, and how that workflow enhances (or sometimes crushes) their creativity, is all that's really important.
It's only the progammers of this world that really have to worry about "drivers" and how to actually get the tune to play. From a programmer's POV, whatever the format, it's all just the reasonably simple juggling of bits and bytes and then writing to the PSG's registers.
The last sound driver I wrote could run both formats: pattern based or command string based. I liked the idea of applying the strengths of command string structure to that of a simpler pattern/list format.
Cool! Is there a demo of that anywhere?
Do you have any plans to release your xm player?
Sounds like Squirrel is going to be easier for a n00b to get up and running, but HuSound might be a little more powerful/robust in terms of raw capabilities, if you can spare the memory and CPU cycles for it.
That's certainly what Arkhan would have you believe.
The best thing is for you to experiment yourself.
There's an online MML editor that you can play with and see if you like it ...
http://benjaminsoule.fr/tools/vmml/
And here's a tune from http://www.reddit.com/r/gamedev/comments/1f9l62/visual_mml_a_text_music_editor
#TABLE0{(0,0,-32,32,-32,32,-32,32,-32,32,-32,32,-32,32,-32,32,-32,32,-32,32,-32,32,-32)128};
#TABLE1{(255,0)5};
%1 @2 na1 t 110 l16 v8
[[[o>> g+ o>r d+ d+]][[o>> a+ o>r f f]][o> c r g g] o> c r o>> g r a+ r o> f r[[o> c r g g]]
[[o> d+ r a+ a+]][[o>> a+ o>r f f]][o> c r g g] o> c r o>> g r a+ r o> f r[[o> c r g g]]]c;
%1 @2 na1 t 110 l16 v4 l16 r r l16
[[[o>> g+ o>r d+ d+]][[o>> a+ o>r f f]][o> c r g g] o> c r o>> g r a+ r o> f r[[o> c r g g]]
[[o> d+ r a+ a+]][[o>> a+ o>r f f]][o> c r g g] o> c r o>> g r a+ r o> f r[[o> c r g g]]]c;
%1 @8 np0
o< l2 g l4 r r l4 f. l16 f d+ l4 f g f l16 r r l4 d+ l16 r r l2 c l4 r r l16 c d d+ f l4
o< g^ l16 r r g+ g f^ d+^ l4 f r o<< c r o< a+^ r r r l16 r^^^^^^^^^ g a+
o< l2 g l4 r a+ f. l32 f g f d+ l4 f g f l16 r r l4 d+ l16 r r l2 c l4 r r l16 c d d+ f l4
o< g^ l8 r l16 g+ g l8 f d+ l2 f o<< d c^;
%1 @8 np0 l32 r r r r v4
o< l2 g l4 r r l4 f. l16 f d+ l4 f g f l16 r r l4 d+ l16 r r l2 c l4 r r l16 c d d+ f l4
o< g^ l16 r r g+ g f^ d+^ l4 f r o<< c r o< a+^ r r r l16 r^^^^^^^^^ g a+
o< l2 g l4 r a+ f. l32 f g f d+ l4 f g f l16 r r l4 d+ l16 r r l2 c
l4 r r l16 c d d+ f l4 o< g^ l8 r l16 g+ g l8 f d+ l2 f o<< d c^;
%1 @8 np0
l32 r r r r r r r r v3
o< l2 g l4 r r l4 f. l16 f d+ l4 f g f l16 r r l4 d+ l16 r r l2 c l4 r r l16 c d d+ f l4
o< g^ l16 r r g+ g f^ d+^ l4 f r o<< c r o< a+^ r r r l16 r^^^^^^^^^ g a+
o< l2 g l4 r a+ f. l32 f g f d+ l4 f g f l16 r r l4 d+ l16 r r l2 c l4 r r l16 c d d+ f l4
o< g^ l8 r l16 g+ g l8 f d+ l2 f o<< d c^;
I don't know about you ... but that doesn't look fun to edit to me!
Unfortunately, a tracker is not a very musical interface, so I've always found it to be a clunky trainwreck to use.
Although Arkhan obviously doesn't like the tracker interface, there seem to be enough other people that do to support the commercial Renoise editor, and the open-source OpenMPT project.
http://en.wikipedia.org/wiki/Music_tracker
http://en.wikipedia.org/wiki/OpenMPT
As mentioned on Wikipedia ... OpenMPT is still being used in game development at places like PopCap.
-
Or, rather than dive into some other example and editor, you could just download Squirrel and use one of the many preincluded examples that are much simpler.
and if you look at the nice manual I wrote, it's all explained pretty good.
I use 3MLE for MML editing in a modern interface, complete with piano roll: http://3ml.jp/
If you do the right amount of investigation before starting and scaring yourself, you'll find that MML is simple.
It's not like trackers are an easily accessible, approachable interface. It's columns of bullshit, often with hex values, and it's all fairly unintuitive.
I made some demonstration videos awhile back too, to demonstrate how non-painful it honestly is:
https://www.youtube.com/watch?v=XeZTqqN0FtM
EDIT: also, that MML example is pretty terrible looking. Don't blame MML for someone else doing a crappy job at editing the thing.
-
MML is so easy that a braindead raccoon could understand it. 3MLE makes it easy enough for a completely dead raccoon to use it.
-
I suspect a dead parrot is another story altogether, however. Are your raccoons zombies, perchance?
-
I suspect a dead parrot is another story altogether, however. Are your raccoons zombies, perchance?
From RACCOON CITY.
HAHHH
Get it.
It's a Resident Evil reference.
-
Since my 7800 project hit engine complete and PC-Engine playtime will be put on hold once the CD-Stupid Cards are finished, I took some time to try and break my sound tools.
Fortunately, there was not much wrong. So I'm releasing HuSound 1.25cz (http://tailchao.com/Audio/index.php#HuSound) which includes the following changes:
-HSCC would crash if its first located instrument or sound effect definition was mangled. This has been corrected and the compiler will cleanly alert the user to the syntax problem and exit.
-HuListen's RUN+SEL reset routine was jumping to the wrong portion of my initialization code (the unswapped MCGenjin cold reset rather than a warm reset). This could cause all sorts of interesting behavior on real hardware.
-The waveform previews in HuListen now render on alternating even / odd frames. I don't think anyone really needs finer granularity than that.
-The HuListen builds now default to 4MB in size (the size of the 4MB Plus development card) and spread the audio data around a little more.
-Small change in HuSound->HuMusic where a ROL ROL ROL ROL AND#$F0 was replaced with ASL ASL ASL ASL.
Unfortunately, I've uploaded the Wario Land 2 covers I did to try and break the driver.
Right now the driver is at a state I'm happy with, and will likely be left alone until / if I come back to the PC-Engine for a full game. For the adventurous, I've listed the actions which I might take if the driver proves too cycle hungry for a project:
-There are currently no alignment / placement restrictions for SFX, Music, and PCM data. This is done to make things easier for the programmer and composer, but locking everything in fixed banks would significantly reduce overhead.
-Music data currently includes an instrument set. This is so the programmer can swap among multiple instrument sets during a song very easily and do generally trippy stuff based upon game context. Not everyone needs this and a global instrument set would be quicker for dispatch and obviously use less space.
-Right now the MCGenjin mapper only has a single bank register, this is an issue since we have to cover three contexts (User, VBL IRQ, and Sample IRQ) an preserve its original state on each switch. Having three (or four) banking registers which may be selected via a context register would be very helpful.
-MCGenjin does not handle reversal of the data written to it based upon its current operating region. The new mapper for the CD-Stupid Card (MCGenjin-CD) does this, and would be a welcome addition to an MCGenjin 2 or whatever mapper.
-
Thanks for the update, I just downloaded it and listened to the tunes on YouTube. :D
-
Unfortunately, I've uploaded the Wario Land 2 covers I did to try and break the driver.
I missed this when I originally saw this thread.
That was fun... I know you will want to upload another example for us... :)
-
Unfortunately, I've uploaded the Wario Land 2 covers I did to try and break the driver.
addition to an MCGenjin 2 or whatever mapper.
Why is that unfortunate? :shock:
-
Haha this is great! I can't wait to listen to people's music based off Hu Cards.
-
Not 100% PCE related, but I've released BupBoop + CoreTone. These are the audio tools written for my Atari 7800 project and Windows PC stuff. It's available for download here (http://www.tailchao.com/Audio/index.php#BupBoop). The SoftSynth is just a wavetable sampler designed to be easily ported to the numerous performant microcontrollers available, such as the STM32 family, then slapped on a cartridge.
This is another SASS target, and there's enough overlap with HuSound to share resources between a PC-Engine and PC-Windows project if the CoreTone driver tick is knocked down to 60Hz.
Like HuSound, no music covers are included with the toolset as I'd like to avoid that legal grey area. However, you can download the tests I did while writing the toolset here (http://www.tailchao.com/Audio/BupBoop/SecretSASS_2015-08-29.zip).
If I ever purchase one of those NEC dating sim boxes to develop for, it will likely result in some odd merger between this and HuSound.
I am so done with audio for the next few years.
-
Does that demo called "Rikki & Vikki : Meet Dut", which features some beautiful sprites =P~, have anything to do with your Atari 7800 project, TailChao :D?
-
Does that demo called "Rikki & Vikki : Meet Dut", which features some beautiful sprites =P~, have anything to do with your Atari 7800 project, TailChao :D?
In short : Yes.
But more on that later :)
-
Does that demo called "Rikki & Vikki : Meet Dut", which features some beautiful sprites =P~, have anything to do with your Atari 7800 project, TailChao :D?
In short : Yes.
But more on that later :)
Cant wait!. Rock the 7800 as hard as you rocked the Lynx with Zaku man! :twisted:. We will all appreciate it! :D
-
Does that demo called "Rikki & Vikki : Meet Dut", which features some beautiful sprites =P~, have anything to do with your Atari 7800 project, TailChao :D?
In short : Yes.
But more on that later :)
I know this is OT, but were can we check on that and your other projects, TailChao?
-
I know this is OT, but were can we check on that and your other projects, TailChao?
I would not worry about OT, we already had over a page of MML vs. Everything Else.
The games will be announced on PenguiNet (http://penguinet.net/index.php), when they're ready. I keep the more personal projects (including tool releases like HuSound) on my portfolio (http://tailchao.com/).
Both of these are a bit barren, and I have taken down a good amount of draft / production artwork since I want things to be a surprise. The Rikki & Vikki footage is just to drum up interest and conveniently mentions nothing of that game's mechanics.
I apologize that it's taking so long for me to finish another game, but I only recently made the leap into doing my projects full time, and had to work for a few years to fund them. But I think the end results will be better for that.
Assuming my estimates are accurate, a few interesting things should show up in early 2017. That is really all I can say for now.
-
OK, sites bookmarked 8)!
Thanks!
-
Alright, I shouldn't be working on this - but here's HuSound 1.3cz (http://tailchao.com/Audio/HuSound/HuSound_v1-3cz.zip).
There was an issue where samples in channel zero were not terminating properly. Playback would stop, but there was a single missing JMP which caused the driver to go and corrupt memory. I've also decided to release all the test covers I did (http://tailchao.com/Audio/HuSound/SecretSASS_2015-11-10.zip) while bringing up the tools. These include the original MIDIs, SASS Scripts, and prebuilt ROM.
After seeing some of the new sound tools around, HuSound's performance needs improvement. So I've decided 1.3cz will be the last version of the toolset to support the original MCGenjin mapper. If / when a future version is released it will use a new codebase and be designed for a new MCGenjin variant focusing on improved driver speed while retaining 100% compatibility with any SASS scripts written for the current version.
-
Cool, thanks! :D
-
I was reading the manual.. how do you do volume and vibrato envelopes?
-
I was reading the manual.. how do you do volume and vibrato envelopes?
All control over an instrument's envelope is done through its macro script. If you look at ./HuListen/SASS/Instruments.txt in the library download or ./Instruments.txt in the Secret SASS download you can see the basic instrument set I've used for most of the test songs and covers.
The big learning curve is that everything in SASS is a script, there are no predefined envelopes. So you're free to do ADSRAR or whatever you want instead of just ADSR.
The first instrument is actually a good example of a volume envelope among other things.
Let's walk through it :
CasioTrumpet
; Approximation of Earthbound / Mother's Trumpets.
; Uses the same waveform as the CasioTone instrument, but has
; a much slower attack phase giving it a brass / wind quality.
;-----------------------
{
wave 0,4,12,24,28,29,28,24,12,8,4,3,2,2,1,1 0,2,6,12,14,15,14,12,6,4,2,2,1,1,0,0
frequency 6 -1
volume 20 2
tuning 16.0
{
rest 4
volume 30 -1
rest 2
frequency 0
volume 28 -2
rest 2
volume 22 0.113
loop -1
wait 9
volume 26 -0.113
wait 9
volume 22 0.113
endloop
noteoff
volume 24 -1
wait 18
end
}
}
The parameters inside the first set of curlybraces right after the instrument name are the initial settings. I set the waveform and initial envelope operations here. We're interested in the latter, which are :
frequency 6 -1
volume 20 2
...The first line (frequency 6 -1) sets the instrument's frequency offset, and how that will change over time. When an instrument is played, its final frequency is the sum of its current note, any active pitch bends, and this offset value. We're setting this to 6, which increases the divider value and gives us a lower frequency. The second parameter of -1 indicates how the frequency offset will change over time. In this case it decreases by 1 per tick. So the pitch of the instrument is increasing.
The next line (volume 20 2) does the same, except for amplitude. We set an initial volume of 20 (out of 31), and will add 2 to it each driver tick. So we're getting louder.
That's our attack phase.
Continuing onward :
{
rest 4
volume 30 -1
...We've hit a rest command, whose argument indicates we're not going to advance our script for 4 frames. Note that rest and wait are interchangeable in instrument scripts, but have different meaning in music scripts. I use both here.
Meanwhile, the frequency and volume envelopes are still calculating in the background. So by the time four frames expires :
Volume = 20 + (2 * (4 + 1)) = 30
Frequency / Divider Offset = 6 + (-1 * (4 + 1)) = 1
Some drivers I wrote pre-add these values on any change, so you need to bias the frame count by one. I think HuSound is one of these. Yay, standards.
Anyway, our next command is volume 30 -1. The volume is getting quieter, and we're starting our decay phase.
Let's skip ahead, since you've likely picked up what's going on by now. A little further down is our first loop :
...
volume 22 0.113
loop -1
wait 9
volume 26 -0.113
wait 9
volume 22 0.113
endloop
...We set the volume to increase and then enter the loop body with a loop count of -1. This is an infinite loop, and it will continue until either the song hits a note off command, is manually stopped, or the channel is taken over by a sound effect.
Looking at the body of the loop, I'm just delaying for a bit, then reversing the direction of the volume envelope, effectively doing this : /\/\/\/\/ ... during the instrument's sustain period.
Replacing this with a frequency command will effectively give you vibrato. You can make the differentials very large and the delays very small to get arpeggios.
Now about note off commands -
We're effective looping in the sustain period above, and will stay there until we hit a rest / note off command in the music script. Once we hit one of those, the instrument script will JMP to the tagged note off area of its script (if the instrument still has control of the channel).
If we look right below the loop body, you'll see :
...
endloop
noteoff
volume 24 -1
wait 18
end
}
The noteoff tag is where the instrument will jump. If you look right after it, I'm setting the volume to decrease and then telling the instrument to terminate.
Hopefully all this is clear! SASS can be a little difficult.
-
Ahh I see. That makes sense.
Heh - I thought some of my engines were too mechanical in nature (I always worried that other people would be put off by the complexity). I can visualize that, though, having created music engines and fussing over ticks and divisors/counters.
-
Heh - I thought some of my engines were too mechanical in nature (I always worried that other people would be put off by the complexity). I can visualize that, though, having created music engines and fussing over ticks and divisors/counters.
Yeah, it's difficult to get a good balance for a scripting language. I'm still not completely happy with some the choices I made in SASS (especially with how 16.8 or 16.16 values are entered). Graphical editors will knock down most of the learning curve, especially for creating instruments.
One nice thing about SASS is that once your very complex macro is written, all of that functionality is reduced to one "using" statement in your music script :
using CasioTrumpet
...
c.4 14
rest 1
c.4 14
rest 1
e.4 24
rest 5
b.4 25
rest 5
...
You can also use abbreviated commands, i.e. "f" for "frequency" or "l" for "loop" when you get more comfortable with the language.
In any case, all of this is still easier than creating patches for very ancient analog synths :wink:
But I would like to write a proper graphical editor at some point.
-
You could always use blargg's sound engine (hes player) source code and interface it with some specific gui/code for your pce sound engine.
Do you buffer your reg changes, so that they all happen near the same time? So pairing channels for phase effects, the channels get updated near synchronously?
-
You could always use blargg's sound engine (hes player) source code and interface it with some specific gui/code for your pce sound engine.
Huh, I didn't think of that approach. That could definitely work.
It's nice that so many tools are being made available :)
Long term I definitely need a SASS graphical suite, since it's being used on more targets than just the PCE. Being able to just draw notes on a staff is great.
Do you buffer your reg changes, so that they all happen near the same time? So pairing channels for phase effects, the channels get updated near synchronously?
Yeah, that's actually one of the reasons the memory consumption is a little high. My Lynx driver doesn't do this since the resources are so constrained, but it definitely helps with the macro setup.
So for HuSound updates you do two calls : one right at the beginning of your VBL IRQ (HuSound_WriteBack) which dumps all of the register updates calculated on the last frame, then one at the end of the IRQ (HuSound_Main) which calculates the next register update set and is interruptable.
-
So for HuSound updates you do two calls : one right at the beginning of your VBL IRQ (HuSound_WriteBack) which dumps all of the register updates calculated on the last frame, then one at the end of the IRQ (HuSound_Main) which calculates the next register update set and is interruptable.
Nice, clean design. :)
-
support the commercial Renoise editor
My friend who is trying to make PCE tunes with renoise is having trouble getting it to export midi's that contain the intended channel information, and also linking the sounds he has access to in squirrel to what he has in renoise.
I have 0% musical knowledge, and about 5% coding knowledge, so troubleshooting for him is so hard hahaha.
Is it a fools errand for him to continue trying to use renoise, or is it possible and cockpit trouble preventing his renoise>midi>3ml>squirrel>huc workflow?
-
OK, switching from the MML back to this one ...
It'd be great if that SASS thing from TailChao had a midi--->SASS conversion.
It has one here (http://tailchao.com/Audio/index.php#MID2SASS), which is also under zlib.
Cool, thanks! :D
BTW ... I've read the HuSound documentation and I have a question for you ...
How do you add arpeggios, vibrato, tremolo, note-transposition, and *musical* sweeps and slides to the tracks in HuSound (the hard-coded add-a-frequency-step isn't *musical*, the step size needs to depend upon the note that was played)?
-
How do you add arpeggios, vibrato, tremolo, note-transposition, and *musical* sweeps and slides to the tracks in HuSound (the hard-coded add-a-frequency-step isn't *musical*, the step size needs to depend upon the note that was played)?
I usually accomplish this by making two or three instruments with manually tuned hard steps to cover a wider frequency range, kind of like how you'd have multiple source instrument samples at different octaves for a sampler.
This is one thing I'm not really happy about, but usually one instrument won't wander around a huge octave range anyway (and to be honest many games don't even bother with this). If that kind of precision is needed you could probably build it into the SASS compiler side to autogenerate more instruments or shove some tables into ROM and let the driver deal with it.
-
support the commercial Renoise editor
My friend who is trying to make PCE tunes with renoise is having trouble getting it to export midi's that contain the intended channel information, and also linking the sounds he has access to in squirrel to what he has in renoise.
I have 0% musical knowledge, and about 5% coding knowledge, so troubleshooting for him is so hard hahaha.
Is it a fools errand for him to continue trying to use renoise, or is it possible and cockpit trouble preventing his renoise>midi>3ml>squirrel>huc workflow?
Renoise pissed me off, so I blame Renoise.
I had the best luck with MODPlug for Windows, years ago.