[CSDb] - User Forums - SDI 2.0 Beta

You are not logged in - nap

CSDb User Forums

Forums > C64 Composing > SDI 2.0 Beta

2006-02-21 18:17

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....

2006-03-09 14:51

Frantic

Registered: Mar 2003
Posts: 1648

@Nata: My intuition tells me that your conversion of GT is not going to be reality. No offence intended.. :)

Salute to those editors/players that DO take physical form and become reality. Like SDI! Horray! (But a packer is still missing, right?)

Will be interesting to have a look at the player code for SDI2.0 later on (that includes HCLs changes and optimizations) as I found the player code/concept/structure for SDI1.8 a bit weird, to be honest. Somehow I find it to be "advanced" through adding features in a cumulative way, rather than just doing the basic stuff (writing to sid) but allow for complexity through flexibility, so to speak. Just a thought. Still I'd like to say a big Horray for it! Certainly one of the best! (Or the best, perhaps, depending on your purposes).

2006-03-09 20:14

Laxity

Registered: Aug 2005
Posts: 459

Quote: @Nata: My intuition tells me that your conversion of GT is not going to be reality. No offence intended.. :)

Salute to those editors/players that DO take physical form and become reality. Like SDI! Horray! (But a packer is still missing, right?)

Will be interesting to have a look at the player code for SDI2.0 later on (that includes HCLs changes and optimizations) as I found the player code/concept/structure for SDI1.8 a bit weird, to be honest. Somehow I find it to be "advanced" through adding features in a cumulative way, rather than just doing the basic stuff (writing to sid) but allow for complexity through flexibility, so to speak. Just a thought. Still I'd like to say a big Horray for it! Certainly one of the best! (Or the best, perhaps, depending on your purposes).

Not sure I get your point there Frantic.. It's an intersting subject, could you please elaborate?

2006-03-09 20:29

Frantic

Registered: Mar 2003
Posts: 1648

@Laxity: Well, to put it somewhat short. What you basically want to do with a player is to be able to set all sid registers, once for each frame (in the standard case), in a quite free and flexible way. You do not necessarily need concepts such as "instruments" and "effects" applied above this. I would argue that they have an inherent "stiffness" (non flexibility). Of course you want _some_ way to organize the sid settings so it does not only become like an uninterpretable blur of data just fed right into the sid. That wouldn't be so nice to work with for musicians. BUT, that doesn't mean that "instruments" and "effects" is a necessary way to organize it. Or rather having a predefined set of parameters included in "instruments" and a predefined set of "effects", each with separate code in the player. For example a "vibrato routine" AND a "slide routine" and soon. (Not even necessarily for the sake of optimizing the player, unless we're talking about the absolutely most stripped down ones, like john player.) These concepts have tended to be taken for granted for a very long time in c64 players/editor, in my opinion. It need not be so.

2006-03-09 21:51

cadaver

Registered: Feb 2002
Posts: 1160

It sounds like you might want some kind of macro-based player. In effect, each channel would have the current note (just to make it somewhat sane), and a pointer to a macroprogram, which could in turn control all sid registers directly, or set pointers to wave-, pulse-, frequency- & filterprograms, delay for x frames, jump into another place in the macroprogram etc.

For maximum flexibility, the macroprograms would not necessarily need to be tied into the channel they're executing on all the time, though for most sane purposes you'd want them to be tied :)

An usual "instrument" would thus consist of a following macroprogram:
- Do hardrestart (whatever way you want it), delay
- Set ADSR
- Set wavepointer
- Set freq/arppointer
- Set pulsepointer (if needed)
- Set filterpointer (if needed)
- End

but no-one would dictate that you'd have to use the macros that way :) And for performance reasons, macros could be converted to machine code embedded in the music data to not require a kind of virtual machine.

Btw. you might also want to look at Stephen Judd's controversial C64 music editors (Blahtune/Tunesmith). Ninjatracker is also a sort of minimalized and simplified macro-based player, there the macro-, wave- and frequencyprogram are the same, and there are some quite heavy limitations.

2006-03-10 07:48

Frantic

Registered: Mar 2003
Posts: 1648

@cadaver: Yes, in fact, that is what I was talking about. Haven't checked Ninjatracker until now really, but I see now that you have some parts of this concept implemented in there, in the wavetable, yep. (Thumbs up for supplying the player source btw! Checking it out right now.)

2006-03-10 09:07

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!

2006-03-10 09:11

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. ;)

2006-03-10 09:17

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!)

2006-03-10 09:44

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...

2006-03-10 09:57

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