| |
6R6
Registered: Feb 2002
Posts: 245 |
SDI 2.0 Beta
Hi.
A working preview here:
http://home.eunet.no/~ggallefo/sdi/
Report your bugs and thoughts here:
GRG |
|
... 195 posts hidden. Click here to view all posts....
|
| |
Laxity
Registered: Aug 2005
Posts: 459 |
Interesting for sure. I'm much for instruments setups, commands etc. as I find this easy to work with, but from a programmers standpoint this is not a very generic approach not beautiful approach.. It is however very functional. One problem would always be that you need to organize your data in some way. This will present some limitations. Most of the players I know of, are programmed in the Hubbard tradition, and are programmed around interpretation of music concepts. One being the concept of rigid instruments. If you have a violin instrument, that is pretty rigid, I'd say.. You can play it in many ways, but it'll always remain a violin.. The concept of the macro based player will make this violin dynamic.. You can in essence shoot holes in it to make it sound different, or transform the violin body to stone.. This is not part of the traditional concept of music, but interesting never the less. . Argh.. Have to stop.. My daughter (5 months) thinks this is boring.. :) .. Will be back.. Interesting discussion! |
| |
Frantic
Registered: Mar 2003
Posts: 1648 |
Sorry if drifting away from the initial topic, but I guess we're in one sense still discussing the player structure of SDI. ;)
@cadaver: Hey, I really liked this particular piece of code:
lda vpulseaddtbl-1,y
adc vchnpulse,x
adc #$00 ; <- THIS ONE
sta vchnpulse,x
I'll rip that one. ;) Did you invent it or did someone else use it first?
@Laxity: Got a 11 month old daughter over here. I know it can be hard to combine, but don't give up! I won't. Only lamers do. ;) |
| |
Laxity
Registered: Aug 2005
Posts: 459 |
@Fran: Well... I've tried it before.. I have a son, age 3 .. It almost feels like routine :)
Edit: Crap... Sorry for all the typos.. That's a consequence of having to hurry I guess... (YEEES.. I'm comming!) |
| |
cadaver
Registered: Feb 2002
Posts: 1160 |
Quote: Sorry if drifting away from the initial topic, but I guess we're in one sense still discussing the player structure of SDI. ;)
@cadaver: Hey, I really liked this particular piece of code:
lda vpulseaddtbl-1,y
adc vchnpulse,x
adc #$00 ; <- THIS ONE
sta vchnpulse,x
I'll rip that one. ;) Did you invent it or did someone else use it first?
@Laxity: Got a 11 month old daughter over here. I know it can be hard to combine, but don't give up! I won't. Only lamers do. ;)
I have been inspired by players storing pulse in nybble-reversed format (for setup) but I think that addition code wasn't borrowed from anywhere, or if it was, it was rather from some texturemapping code on PC :) I guess most coders/musicians won't tolerate that 8-bit pulse modulation horror... |
| |
j0x
Registered: Mar 2004
Posts: 215 |
Interesting discussion.
I'm a big fan of the "program-your-own-instrument" approach. I did this on a player I did last year: Every SID register (8 or 16 bit) ran a script that could do simple operations like storing, adding and jumping. These scripts were controlled by starting/stopping notes and by explicitly starting and stopping scripts. That was extremely flexible, and worked very well. The player was very short for its flexibility, but it did take a lot of rastertime (slightly more than JCH's last player (20G4?)), so now I'm doing something else: Allowing the musician to code his instruments in assembler. That gives you a lot of freedom in choosing SID register write order, etc. Obviously, this "meta-player" approach is not very suitable for the non-coding musicians (sorry!). OTOH, in all probability, I'll be the only one ever using it :)
I haven't looked at the SDI 2.0 player (is it available yet?), but I assume it's using the "Hubbard concept".
/j0x |
| |
Frantic
Registered: Mar 2003
Posts: 1648 |
@j0x: The latter approach sounds quite cool, albeit a bit cumbersome too I guess. I thought about it too, but scrapped the idea. If I would do it, I would do it the way Cadaver also suggested here, by converting tables of data into to code. That would also get rid of the raster eating "virtual machine" as he called it.
@j0x: Yes, SDI is along the lines of the Hubbard tradition. |
| |
Dane
Registered: May 2002
Posts: 423 |
You want a flexible editor and a streamlined finished product in terms of rastertime and/or memory usage. I can recommend assembler optimizing once you're done with the composing bit. |
| |
Bamu®
Account closed
Registered: May 2005
Posts: 1332 |
Quote: Hehe, Thanks :) I have a early light version of sdi from 1994.. have a look :
http://home.eunet.no/~ggallefo/pix/oldgt.png
Btw, How do i display pics in my posts ?
Murdock: I dont have a double sid myself. But if I had one
I would do it just for the fun :)
and where can I download it? :-O |
| |
soci
Registered: Sep 2003
Posts: 481 |
Hi GRG!
I'm not much into composing music, but may I ask why SDI includes an NTSC sound table? It's more than a half note off on pal systems.
I've noticed this problem with DMC first, as a lot a years ago Perplex/Singular complained that there's something wrong. He composed on a synth and then had trouble with converting he's works to C64, as even shifting notes was not accurate enough.
Is there any possibility to include a selectable pal table? I can send you a corrected one for SDI.
I understand that simply removing the false ntsc table would ruin the unique SID sound ;)
|
| |
6R6
Registered: Feb 2002
Posts: 245 |
Soci: I was unaware of this, send me your paltable so i can check.
|
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | ... | 21 - Next |
