A little note on option 3: we shouldn't go for a new chip just because you can't seem to get any Micro Cabin quality results from Moonblaster, just to name something. We obviously need different software for that, not a new chip. And you can replace 'tracker' with anything else which is relevant of course, but I had a character limit of 50 on this poll option.. ^^
Ofcourse I'd buy a new soundchip... Just cuz it's fun...
It should have a lot more rom and quite some ram, but most of all some fx chips to make the sound sound like it should sound and not flat and dead like it is in moonsound.
I once discussed the option to make an interface for the MOS chip with vortexion. Would be nice though. But I'm sure a lot of people disagree. BTW: what is a new soundchip? Old but never used? Or new as in new? X-Fi?
Could be anything. An FPGA implementation of some design, a 'ported' chip. The discussion is opened with the ever-returning vicious circle of acceptance, support and audience. It's all very complicated I think.. ^^
If you 'port' a SID chip to MSX then you're likely to get comments like 'Uhuh, that's a C64 chip! Buzz off!".
If you 'port' some relatively advanced EMU/Creative wavetable chip to MSX (Moonsound 2) then you're likely to get comments like: "Let's not turn an MSX into a PC", or: "dude, FFS, use the Moonsound".
If you design a new synth using FPGA in either the 1cM or an FPGA-based extension then you're likely to get comments like: "it's not really an MSX chip, it's only an implementation, there's no userbase, there's no software, oh and I don't have an 1cM" etc.
Sometimes MSX is like politics, so many parties who never agree on anything.. That's the disadvantage when there are so many extensions available, there's no De Facto MSX.
a cheap midi interface could help for developping music , it is not a new sound card but still a piece of hardware.
tracker could be running on PC's ...
If you 'port' a SID chip to MSX then you're likely to get comments like 'Uhuh, that's a C64 chip! Buzz off!".
If someone "wastes" his time to 'port' SID chip to MSX, I surely will not give comment like "Uhuh, that´s a C64 chip! Buzz off!".
Instead of that, I´ll give a comment like "WOW!! THAT´S A C64 CHIP!! You are welcome to Buzz my doorbell to bring it to me!!"
It would be nice to get some BASIC command(s) to program our dear beloved SID! See, I already talk about SID like it had always belonged to MSX standard!
Just 'port' SID to MSX, arguing MSX(1,2,2+,R)ers don´t need anything else!
If there's one difference between the C64 scene and the MSX scene then it's that all the C64 noses are pointing into the same direction, whereas ours are pointing into every direction possible.
If there's one difference between the C64 scene and the MSX scene then it's that all the C64 noses are pointing into the same direction, whereas ours are pointing into every direction possible.
Well... maybe that´s because there are no C642s, no C642+s and no C64Rs I think they do not think Amiga VS. C64 samelike like here people think MSX < MSX2.
Who would mind destroy a few C64's to make a cool new soundcard for MSX ?
I would love to get that C64 sound comming out of my MSX combined with a SCC or something....
I actually played a lot of games on that... thing, I admit. But I never liked the sound in particular.
The sample Hz seemed to be better allright (compare Activision's "Ghostbusters" ), but that doesn't make the sound IMHO.
Well, from today's perspective it's not super-special or something, back then it was a rather advanced chip though. While it has some underground stuff like filters, ringmods 'n such I don't think it has much to bring in against DS6, Space Manbow, Illusion City or Xak TToG.
Who would mind destroy a few C64's to make a cool new soundcard for MSX ?
I was thinking that maybe some freak wants to construct sid -CLONE- from scratch.
I don´t like the idea of hardsid, or anything else, which needs destroying of old machine.
Well it´s surely a matter of taste, but I love the sound of SID. Have always loved and will love eternally. Just hear "Pitfall II" on Commodore 64 on example.... and many more...
Sid seems to be particularly good at creating lively and 'wavely' sounds, you know what I mean. Then again I've yet to hear a crisp and clear tone come from it, which is the strength of the PSG. Compare the purity of MoG's Demeter tune for example.
I'm positive that if we want more lively and less 'flat' music on PSG, that's very much possible when good coding and composer skills are combined. Currently everybody who wants to create better music seems to jump to more advanced soundchips that were made for the MSX.
Huey: as unnatural as it may sound, your practical replayer issues (cpu load, mem size) are exactly what shouldn't be the primary goal for a new tracker. For one thing: it's not the coder of a tracker (or any other music tool) who should decide how heavy your format should or should not be, it's the composer and the coder of a game/demo who should decide. The best tracker/tool is one which allows everything there possibly is. You want 9 instrument-changes, volume-changes and frequency-changes on one line? You shall have it. Whether your replayer can cope with it is verse 2, and whether your product is a cpu-friendly musicdisk or a heavy game/demo is another verse. It could be that this means that the format is quite complex and mem-heavy. Again this is or should be the choice of the ones who're going to use the music in a production. A coder could tell a musician: "max 20 events per int" or "max 32 'cpu-load' per int" when events differ in cpu-load. Whether that musician then applies all these 20 events on the first 5 channels, or spread across the whole line is up to the composer. It should at least technically be possible. If the format is like .mod, then you get columns for notes, instruments, volume and effects. That's like 4 or 5 events per step, whereas Moonblaster/wave/fm (and other trackers as well) have only 1 event per step. So, Moonblaster may be more efficient, but 1) it offers far and far less flexibility, and 2) all events are put on 1 channel, whereas .mod style columns are separated from eachother. It could very well be that individual columns are easier to RLE because of the uninterrupted repetition of events.
MJTT uses exactly this mod format btw, although we convert our whole channels to an event-stream, kinda like MIDI.
But.. let's await NoWind in 2009.. I somewhat had the idea of making a tracker on PC which controls the MSX via NoWind. The only thing I need to do is upload events to the MSX, where it'll be put in memory, and a replayer on MSX will playback what's in mem (upon sending start/stop events). The advantage of having an editor on PC is the much larger resolution and the greater ease to make an interface. In my case the advantage would be that this interface would be made by a composer, rather than a coder )
@wolf: Yes, I look at it from a another perspective. I was looking at it from a whole (composer, coder and pixeler). I was thinking in terms of Vortex tracker II. Which is in my opinion very composer friendly. But again if you make a whole production its all about compromises. Even for a composer
But you don't always need compromises. For instance for an intro demo with little animation, a title screen, etc. can soup up much of the cpu in the replayer. In fact, all of MJTT didn't need the cpu time for anything else either (otherwise we'd have been screwed ). Probably only tightly timed high performance action games need to be really conservative.
Do you like SID or do you like the music that SID happens to produce?
If the latter (and I'm sure many people agree) that's currently a challenge for musicians using the PSG, regardless of whether we port SID to MSX. Take themes such as Masters of the Universe or Skate Air. I think these are quite good examples for musicians who want to create SID-like music for MSX.
hmmm, interesting info wolf_.... A lot of current trackers for old platforms don't take any games or demos in mind,
but are there purely for composing. Would a lot of msx trackers have suffered from CPU compromises ?
Dunno, there are a few things to keep in mind tho. When I look at the -what I think- most successful MSX trackers:
- FST family
- ProTracker
- Moonblaster classic
Then what these have in common are that all channels of a pattern are on a single screen. MOD-style formats usually need scrolling, as MBFM and MBWave do. Perhaps it was a choice back then to try to have everything on a single screen. This would exclude extra channels unless people would choose to have hidden channels one could toggle.
Memory was an issue. More songdata = more memory.
All these programs are fairly old by now, mid-90's at most. That's like 15 years ago, surely the programmers back then may not always have been as superskilled as they possibly are today.
Tracker-programmers from this era were typically game/democoders, and creating an interface for a creative tool, thinking about functionality and workflow is clearly something differently.
Tracker-programmers from this era may have been influenced by the composers of their group, which may be good or bad. Fact is that us MSX'ians have basically started with structural composing since FST, and only for a few years when the last-ever trackers emerged. Not everyone had an alternative system (like an Amiga) standing next to the MSX, so any knowledge about -for instance- mod-style composing was probably non-existent.
And yes, the scene was about demos and games, so there was probably a situation where music had to be as cheap as possible.
Do you like SID or do you like the music that SID happens to produce?
If the latter (and I'm sure many people agree) that's currently a challenge for musicians using the PSG, regardless of whether we port SID to MSX. Take themes such as Masters of the Universe or Skate Air. I think these are quite good examples for musicians who want to create SID-like music for MSX.
Hmmm... it feels a bit same to me as if someone asks me, "Do you like V8 or do like the sound that V8 happens to produce?". I surely will answer, that I like BOTH! I like the music that SID happens to produce so I like SID, and Commodore 64 too.
But I still like the idea of having SID-clone in MSX cartridge!
And I surely support all MSX composers who want to make PSG sound like SID. Or should I say, I surely support all MSX composers who want to make PSG sound GOOD!
By the way, I still remember that LONG time ago, *I* managed to get SID like sounds with "just" my very simple and short BASIC program. So it can´t be too hard for good composers with good trackers, I guess.
S and M are not 100% perfect. For a consistent sound the M value usually needs to be in sync (frequency-wise) with the freq of the psg tone, which is not always possible, iirc.
And it may be my complete noobness, but when trying to make music in Basic I get the effect that the three channels go out of sync. As in: various tones of certain length do not add up to the exact same duration as I would expect mathematically. That alone takes away all joy in trying to create tunes. No, I do not need another soundchip or tracker, I need a Basic PLAY statement that works!
I know exactly what you mean.
Don't worry; it functions perfectly.
It's only that MML tone/rest duration notation works differently than you might expect.
I never even learned to read those musical symbols
But what I meant was that I expect one channel only using x8 notes will stay in sync perfectly with another channel using only x2 and x4 notes (but apparently with 2 or 4 times as many tones). Unfortunately the two channels will drift away and start mismatching. That surely shouldn't happen?
Well, it *is* BASIC, which is as slow as a Hippo in a pool o' peanutbutter. After each string has been processed, a new string must be parsed. Long strings may take longer to parse or manage. I'm not sure, but I think it's something like that.
At times I've thought it to be wiser to update music at fixed intervals (like rows in trackers) and read out a new row from data statements. Essentially you'd be using the sound command then instead of the play command.
More wise would be to use a PSG tracker/tool to compose, and use some BASIC-replayer for playback in BASIC.
Nah, if the problem would be the BASIC slowness, then there would be a lag between new parts to ensue playing, and not between channels within the same part.
I've seen and heard (Japanese) perfectly flowing MML songs using all 9 FM-Pac + 3 PSG channels, using strings and not DATA lines.
I think the problem here simply is:
Discrepancy in tempo between channels.
Make sure all channels have the same tempo, else you'll indeed get some avantgarde stuff!
You know how to set tempo, right?
BTW when you add a point "." after a tone/rest, you'll get the 1,5 rate, don't forget.
Lastly, wolf_ is right, better use a tracker!
Unless you really want to do it in MML, hey, it's your party!
I'll try to find a sample where it failed, and recheck that it indeed set the tempo equally. But I'm sure I already checked that.
I was flabbergasted that the flaw appeared exactly the same across emulators.
The speed discrepancy progressed quite regularly as the tune went on, it wasn't a particular tone or . that made it fail.
Hrothgar, sorry I don´t have that BASIC listing around, I am pretty sure I didn´t SAVE it, as I was just experimenting for fun, but if you are lucky, some ideas may have been "saved" to my paper "archives", different thing is, do I find it from that "archive".
It´s sure, that you can make really cool effects using play-command´s S and M. But also, it usually is very irritating to found out, that when you make ABSOLUTELY COOL background sound/music with play command, and compose melody in your head for that absolutely cool background sound/music, and then you write that melody into BASIC and put play command to play them both at the same time, that melody and absolutely cool background sound/music, and result is.... ****hear fanfares now**** horrible garbage!!!!!! Somehow they destroy each other, but when you play them separately, all is fine again.... damn play command!!!!!!!!!!!! But despite that darned thing, it is possible to make SID like sounds with just plain MSX-BASIC! Just start experimenting, like I did!
Comments (42)
By wolf_
Ambassador_ (10092)
17-11-2008, 15:08
By meits
Scribe (6533)
17-11-2008, 22:42
By evulopah
Paladin (669)
18-11-2008, 10:11
By MäSäXi
Paragon (1884)
21-11-2008, 11:02
By Sander
Founder (1871)
22-11-2008, 00:50
By wolf_
Ambassador_ (10092)
22-11-2008, 01:32
By Leo
Paragon (1236)
22-11-2008, 08:53
By wolf_
Ambassador_ (10092)
22-11-2008, 11:46
By poke-1,170
Paragon (1783)
23-11-2008, 06:58
By MäSäXi
Paragon (1884)
25-11-2008, 10:54
By wolf_
Ambassador_ (10092)
25-11-2008, 22:12
By MäSäXi
Paragon (1884)
27-11-2008, 12:18
By MäSäXi
Paragon (1884)
27-11-2008, 12:22
By Moniz
Champion (400)
27-11-2008, 22:03
By JohnHassink
Ambassador (5665)
28-11-2008, 01:28
By wolf_
Ambassador_ (10092)
28-11-2008, 13:16
By poke-1,170
Paragon (1783)
28-11-2008, 19:00
By Huey
Prophet (2694)
28-11-2008, 21:18
By MäSäXi
Paragon (1884)
01-12-2008, 10:44
By Hrothgar
Champion (479)
01-12-2008, 11:49
By JohnHassink
Ambassador (5665)
01-12-2008, 14:32
By Huey
Prophet (2694)
01-12-2008, 16:06
By wolf_
Ambassador_ (10092)
01-12-2008, 16:40
By Huey
Prophet (2694)
01-12-2008, 20:59
By Edwin
Paragon (1182)
01-12-2008, 21:35
By MäSäXi
Paragon (1884)
06-12-2008, 12:51
By Hrothgar
Champion (479)
06-12-2008, 13:52
By poke-1,170
Paragon (1783)
15-12-2008, 04:00
By wolf_
Ambassador_ (10092)
15-12-2008, 12:08
By MäSäXi
Paragon (1884)
16-12-2008, 10:13
By Hrothgar
Champion (479)
16-12-2008, 15:43
By JohnHassink
Ambassador (5665)
16-12-2008, 16:43
By JohnHassink
Ambassador (5665)
16-12-2008, 16:47
By wolf_
Ambassador_ (10092)
16-12-2008, 16:50
By Hrothgar
Champion (479)
17-12-2008, 08:21
By JohnHassink
Ambassador (5665)
17-12-2008, 10:42
By Hrothgar
Champion (479)
17-12-2008, 11:59
By wolf_
Ambassador_ (10092)
17-12-2008, 12:20
By JohnHassink
Ambassador (5665)
17-12-2008, 12:31
By Hrothgar
Champion (479)
17-12-2008, 12:59
By JohnHassink
Ambassador (5665)
17-12-2008, 13:18
By MäSäXi
Paragon (1884)
18-12-2008, 11:34