| |
St0fF
Registered: Oct 2002
Posts: 40 |
Music Trackers - what should a new one be able to handle?
Hi All!
As I'm working on a new tracker and have some sort of concept done, I guess it's best to ask for some comments.
Basic Concept:
-tracking of up to 32 tunes
-> out of memory error included!
->consisting of 4 tracks - one for each voice and one for the filter
- completely reconfigurable speed, two speed-steps
- up to 128 sectors for voices 1..3
- up to 128 filter-sectors
- duration-dependant player, duration independent editor (evry note occupies 1 tick while editing)
- up to 128 instruments (defined by adsr, wave-pointer, pulse-pointer)
- up to 256 Wave-effects
- up to 255 Pulse-effects
- up to 128 Filter-effects
- multispeed-capabilities, handled by the player, you just have to supply the right music-calls ;)
- Player-Calls:
JMP PLAYER ... Akku = tune_num: initialise tune
JMP PLAYER+3 ... standard play_call
JMP PLAYER+6 ... set Global volume to #Akku (for fadein/fadeout purposes)
Tracks: normally point to sectors
Commands: Transpose up/down -$1f..+$1f Halftones
loop track
end track
set global volume (D418)
play song X (so you can make a song out of subtunes ;)
repeat following sector N times
Sectors: do play Notes with Instruments ;)
one tick can consist of the following parts:
- Instrument selection
- ADSR - tuning
- wavepointer - tuning
- pulsepointer - tuning
- global tickspeed - tuning
- Note - Description:
can B: pure Note - just play note using the settings above
glide Note - glides from one note to another with a precalculated glide-add-value
tied Note - just play without restarting the Instrument ... like a freq-change
slide Note - slides from the actual playing frequency to the new note's frequency without restarting the Instrument using a precalculated slide-add
wait tick - just waits
switch gate - switches the gate's status
voice off - turns off the Instrument, resets $d404+(voice_offset) to (09 & gate_status)
huh ... and that was just the upper level ...
Instruments: consist of ADSR, Wavepointer, Pulsepointer
- the Pointers point to Effect numbers.
Wave-effects:
consist of lines ...
which consist of:
- Commands:
- change instrument update speed
- tremor (halftone offset,speed)
- vibrate -> with a given vibrato-width, vibrato-speed, vibrato-delay, and vibrato-direction
- slideaway -> a function dedicated to drum'n'bass music, using vibrato parameters
- off -> works like voice_off, but from inside the instrument
- loop -> loops to another line of the waveeffect
- a Waveform prepared for $d404+(voice_offs), with the Drum-Mode coded into the reset bit (bit3), #8
- a transpose value to be added to the played note to gain the actual frequency __or__ the HIbyte of the frequency if the drum mode was specified
PulseEffects:
also consist of lines
consisting of:
- pulse_set (adjusts $d402/3+(voice_offs))
- pulse_add (sets an 8bit adder and an 8 bit counter)
- pulse_fine_add (16bit adder, 8 bit counter)
- set_delay (sets a 4 bit value of playcalls to wait until the next pulsemodification takes place; none of the following commands are possible if set_delay is specified
- end_pulse
- loop_pulse
Filter-stuff ... it's better to show this on its own
Filter-Tracks ... equal to normal tracks
Filter-Sectors ... do play Notes with Filters ;)
one tick can consist of the following parts:
- Filtereffect selection
- Filterinput selection (which voices 2 filter)
- Note - Description:
can B: pure Note - just play note using the settings above
wait tick - just waits
NOTICE: due to the fact, that the filter itself is regarded as a voice, we supply the basic filter cutoff frequency with the note we play. We can now do Filter-Arpeggios instead of just making some linear motions. We can also do logarithmic motions thru filter-arpeggios ;)
Filtereffects:
consist of lines ...
consisting of any of the following functions combined:
- frq-mode selection (how to translate freqs - as notes or linear)
- Filtertype & -Resonance set
- Frequency set (depending on the frq-mode this is either a halftone_steps_to_add_to_actual_note or a hibyte of a cutoff-freq.)
- set Add - supplying an adder and a counter, some motion is established (for linear: you supply a 16bit addvalue (i know only 11 bits are used for cutoff-freq.); for note_mode: you supply an 8bit adder of how many halftones to add each step)
- set Delay: number of calls to deleay the next filterchange (none of the following commands can be used if this one is used!)
- set freq Fine - sets the 16bit value supplied as filtercutoff, regardless of actual freq-mode
- end filter - stops working on this filtereffect
- loop filter - jumps to another line in the fltfx
Well, this was a damn lot of stuff regarding the structure of 'upcoming' musicdata. A few things left:
The editor manages music memory dynamically, so a sector only takes what it needs while it is not edited. This way we should be able to manage even 32 songs.
Ok, any comments are welcome,
St0fF/Neoplasia
. |
|
| |
Steppe
Registered: Jan 2002
Posts: 1510 |
Really hard to judge from your descriptions only, but it sounds awesome. Don't neglect the handling of the tracker, because the steepness of the learning curve will greatly influence the amount of people using it, IMHO.
Keep up the good work, and keep us informed about the project! |
| |
Merman
Registered: Dec 2002
Posts: 140 |
Sounds cool. Here are some ideas from other editors that would help...
- equalizer/analysis (like DMC v5)
- live play function for testing voices, and/or a step/record function (saves keystrokes to a sector)
- "intelligent" disk function i.e recognises its own files
- save to RSID/SIDPlay format
- good copy/paste functions
|
| |
St0fF
Registered: Oct 2002
Posts: 40 |
> - equalizer/analysis (like DMC v5)
... how'd you like it, like in ATMDS 1.2?
... for that, try the atmds v1.2 from www.tu-ilmenau.de/~sthu-mtr/c64/files.html
> - live play function for testing voices, and/or a step/record function (saves keystrokes to a sector)
... i planned a keyjazz function able to distinguish 3 pressed keys at once, which shall give all 3 voices the appropriate (actual) instrument and the note according to the keys. Maybe _direct_record_ or something will be c0ded, too.
> - "intelligent" disk function i.e recognises its own files
... again a functionality that atmds will have by default since atmds 3.2 ;)
> - save to RSID/SIDPlay format
... great idea!
> - good copy/paste functions
... those will grow with the c0de of the editor - and I'll keep you up to date on it ;) |
| |
Hate Bush
Registered: Jul 2002
Posts: 462 |
Saving to RSID isn't necessary, unless your plan is to include digi-channel support. |
| |
Richard
Registered: Dec 2001
Posts: 621 |
My idea would be a music editor that can handle player routines, from DMC, USA Music Assembler/Voictracker, Music Mixer or anything like that :) A music editor that uses less raster time, even less than Goat Tracker. Live play, recordable music and a very nice GUI. |
| |
Stryyker
Registered: Dec 2001
Posts: 468 |
I'd rather use more rastertime than GT to enable better effects or smoother sounds.
I dislike the idea of the filter channel as I see this only making a resulting file grow too much. |
| |
dalezy
Registered: Apr 2002
Posts: 476 |
i think a functional gui is important to me. if the whole thing looks like a mess, i'm like unable to do anything with it as i really hate unnessecary learning processes that come along with hardly understandable programs.
the filter-tweaking part is nice, but maybe that could be implented in sort of slide comments, like the ones in jch.
hardrestart/no hardrestart, tremolo, aswell as the ability to change the adsr inside the instrument settings would also rock as features.
there's prolly more, but that's all that comes to my mind right now.
|
| |
Dane
Account closed
Registered: May 2002
Posts: 421 |
Unnecessary to make new music programs, when you can easily adapt those already existing to your purposes. My advice would be to devote that time to making good music instead. There are just so many tools, and unless you somehow manage to hack 2-3 new voices to the Sid, it's all been done before. |
| |
Akira
Registered: Oct 2003
Posts: 52 |
I would liek one that fully utilizes the C64 sounds through a MIDI controller of choice. While there are AWESOME trackers that squeeze everything out of the C64, none of them let you control tihs power through MIDI.
At least let's make one with a CV gate or something :P
Cheers |
| |
dalezy
Registered: Apr 2002
Posts: 476 |
akira, in this case you might want to try this: http://www.ucapps.de/index.html
(warning, the guy who did that is called to be insane) |
| |
Akira
Registered: Oct 2003
Posts: 52 |
Yup I've seen that one! Impressive innit!
What I was talking was of using a C64, nothing as complex as that (no hardware mods maybe except the creation of a MIDI interface)
I have such a project in mind but I cannot code to save my mom so I am stumped just with my ideas and graphics :( Maybe someday I can code, or maybe someone wants to have a look-see at my project and if he likes it he might want to code it! (wishful thinking? probably).
I will start with teh hardware side of things, modifying a C64 only a wee bit... Won't look as mad as that link, but the good thing is that it will STILL be a C64 (perfect for SID playing :D) |
| |
Puterman
Account closed
Registered: Jan 2002
Posts: 188 |
No, Akira, there aren't any "trackers" that squeeze everything out of the C-64's sound capabilities. No editors are expressive enough to give you the capabilities you have when programming. However, this isn't a big problem, as most people seem to be content with the features of a normal editor.
As for controlling the C-64 through a midi interface, I suppose you've checked out midi slave? |
| |
Akira
Registered: Oct 2003
Posts: 52 |
My goal is ambitious as hell and it's not going anywhere if I don't start learning asm for the c64 :P.
I have checked that one out too, but still no dice. I'm a picky mofo.
Maybe no tracker squeezes all the SID chip can do, but I liked GRG's one pretty damn much |
| |
LordNikon
Registered: Dec 2001
Posts: 42 |
I would say it should have have the same edditing like protracker on amiga or odin tracker on the C64... and it would be too bad if you could save your instruments.. |
| |
Pater Pi
Account closed
Registered: Jan 2002
Posts: 121 |
hm. did you mean it the way you wrote or would you like to have the possibility to save instruments? i'd like the last one . |
| |
dalezy
Registered: Apr 2002
Posts: 476 |
saving instruments? why for?
it's not that it's hard to do new instruments from scratch or remember how to do a certain sound. tweaking is the key, you know. =)
and unless you're going to do a 40 rows long drum sound for a 12-speed tune that you want to use more than one time, i don't really see a reason to save instruments. |
| |
Stryyker
Registered: Dec 2001
Posts: 468 |
One of the DMC 5's saves them I think. future Composer does too. |
| |
cadaver
Registered: Feb 2002
Posts: 1160 |
When instruments share common tables for wave,pulse etc. the code to load/save them might become quite hairy. :) Especially when same table entries can be re-used between multiple instruments and you're loading over an existing instrument.. |
| |
Pater Pi
Account closed
Registered: Jan 2002
Posts: 121 |
Well the reason could be described in one single word: lazyness.
Why to make a new basedrum etc. for every tune? And you can also use the instrument as a basic for a new one.
I somehow do miss this in SDI for example (: |
| |
Dane
Account closed
Registered: May 2002
Posts: 421 |
Pah. Don't recycle your instruments. |
| |
dalezy
Registered: Apr 2002
Posts: 476 |
paterpi, but laziness doesn't get you anywhere, imho. always the same sounds make your tunes boring, whatever different melody/bassline the whole thing is based on.
i think so far i've recycled exactly one bassdrum, because i was excited that it turned out that way, but other than that all my sounds are beeing done from scratch, which maybe makes the tunes unique in a certain way (plus the production way always turns out different =). |
| |
6R6
Registered: Feb 2002
Posts: 245 |
Pater pi: Free Memory left in SDI is around $0300 bytes, I'd rather use that for other things than a save-instrument routine. |
| |
LordNikon
Registered: Dec 2001
Posts: 42 |
@ParterPI: Hehe, right. I wanted to say "it would(N´T) be to bad.... "
|
| |
Akira
Registered: Oct 2003
Posts: 52 |
CyberTracker lets you save instruments. I think it's handy, because I don't use to remember all the shit I experiment with, and you can tweak them later on transforming them into new stuff. |
| |
Twoflower
Registered: Jan 2002
Posts: 434 |
I laid sleepless the other night, and suddenly my mind slipped into some more or less comfortable thoughts. I remembered this thread, and an earlier discussion with Dane concerning what the JCH'ed lacked.
In my opinion - the one thing the JCH'ed really lacks is a decent effect-table. Just like on Amiga or PC-trackers. And I want it on every single note so that I might be able to switch both vibrato/speed/sound/macropointers and whatever I feel like - on every single note. "Well, it isn't possible", you say. "The C-64 char layout is only 40 chars wide!". Well, then don't do it 40 chars wide. Do it 54 or sth equally dividable. Should work out fine. And why in the heck do you need 7 digits for entering a vibrato (f.ex S03 -> 60 32) when only 2 really is needed (entering V0 for 60 30 and V2 for 60 32). If you have dedicated places for these, you wouldn't even have to care for the "V", but I think keeping that makes it more flexible. Look at my example;
A#3 01S4U2
--- ------
C#4 01S3V2
The above example should slide up the note A#3 with speed 2 so it reaches C#4 when it's played (=U2). Furthermore, the general speed of 4 for the entire tune is activated (=S4) while playing the note with the instrument 01 (=01 - first row dedicated to sound). Changing the macropointers for the current sound should be done with entering any value in effectcolumn one or two. This leaves any single parameter save for A-F available for describing effects to the player/editor. F.ex "P" for portamento, G for gate on/off, M for adding that cheap kind of arpeggio you have in PC-trackers, etc...
This leads med into the second issue. Splitspeeds. I find it annoying not to be able to make music splitted in the speeds like f.ex 6/4/2 (three different speedmarkers or more). This might also make it able to individually slow down the tune, without having to spread over more than one or two patterns for a slower passage. Many tracked tunes have used this option.
Third issue. Rastertime. I think there are two needs today. One for making tunes with low r-time, fitted to Grahams, Crossbows, Krills and HCL's purposes, and one for making quality sounds fitting for all music compos, etc. So, why aim for low rastertime? People don't to extremely timed spritemultiplexers anylonger, and in the case they do, there are plenty of players able to achieve what you need. Nah, make a player which takes some r-time and/or make use of $01-$50 or sth similar. :-) And who updates all the sounds and all the effects every frame. Then we're talking nice stuff. Think this over! |
| |
Dane
Account closed
Registered: May 2002
Posts: 421 |
Hopefully, I'll be able to release a relatively userfriendly version of the JCH-editor/packer/player in the future. In the meantime, keep stacking these suggestions. |
| |
Stryyker
Registered: Dec 2001
Posts: 468 |
Or use a jump to a table sort of like SYNC but more like SDI, a program. For the effects that are either on or off, combine upto 8, sort of like DMC 4 did for instrument effects.
If screen space is limited, use you 3 columns as usual but add a 4ths for extra data that can be jumped to from current voice. Sort of like the old sector editor in DMC/FC. Although you can't see all 3 voices at once, you can see 1.
I guess these ramblings make it obvious I don't handle trackers well :(
ADD:
I'm with Twoflower about raster time. 99% of the time sound quality will make 0 difference code quality in the demo or production. Someone can always make raster restricted player version later. |
| |
St0fF
Registered: Oct 2002
Posts: 40 |
Twoflower:
cool vibrato with more usability than 'just' vibrato needs 5 nybbles. starting direction(1 bit), strenth(3 bits), width(one byte), delay_till_start(one byte)
This is a vibrato able to do cool d&b-FX and even more. Variable slides via vibrator and so on.
So don't tell wrong things some ppl have made up their minds ages ago!
Regarding rastertime: some of the most sophisticated players still need more RT than neccessary. It's a compromise between playersize, zeropage-usage, how direct you use your data, and work-scheduling inside the player!
There are two basic ways to minimize Rastertime: do a cut on FX / player-possibilities OR c0de a simple work-scheduler like atmds 3.2 has (look at rastertimes of my tunes - atmds 3.2 is a full function player with an average RTM of less than $10, max i ever seen $1a)
And a last question for twoflower: have you ever thought about how the music with all your FX will look in memory and be managed by the player? From your post it looks like NOT.
cadaver: ATMDS 3.2 has an instrument-save option, but the c0de is so hairy, that it is even hard to find the left over bugs (which appearently are there).
St0fF ... starting to ignore akira and twoflower because of lameness (sry, but i'm just honest)
|
| |
Twoflower
Registered: Jan 2002
Posts: 434 |
Yeah, sure. Ignore me and call me lame.
I'm just the guy that is convinced that there are ways to do a player suitable for musicians, and i'm aware it'll take quite some rastertime. From your description, your player sounds just like a run-of-the-mill player with some nice code, although with functions fitted to make drum'n bass music. Just about the same as the other 200 available players - save for the d'n b that is. Although I agree with you on the case of the vibrato, the necessary values could be easily stored in another table and the "V1" might just be a pointer to that table. But for my needs - a precalculated vibrato fits just fine.
Concidering most of the other stuff, I think you're way out. What i'm saying is that you SHOULD'T compromise with usage of zeropages, nor rastertime, nor how much memory it'll use. I'm not interested in if a routine takes 10 lines or 50. There are plenty of compromise players with "intelligent" routines cutting r-time, made to impress, so why make another? What's lacking in this scene is a routine which gives the best sound and usability for the musician, at any cost! Just compare the amount of tunes released in musiccollections, musiccompos or directly in HVSC with the actual amount of tunes used in productions. It's about time that the music will have a chance to stand for itself. Have you, btw, ever taken a peek at the playercode for last routine the brothers Follin used? Ste Ruddy's using a staggering amount of zeropages there, and still the r-time usage is quite heavy. Noone still matched that one, and it still worked just fine along with Ghouls&Ghosts.
And sure - the result in memory would probably be quite annoying, although nothing unable to handle. Just reserve about the double memory for the patterns, reading the effects as a separate pattern linked to the notepattern. To make it use less mem, do it like in JCH's and use a packer in the end to remove the spaces and change the pointers. Managing it with a routine that updates the filter, pulse, vibrato and sound every frame would most probably take a hell of rastertime, but concidering that - look above. And hey - Amigamod's have a great structure which you could rely on. There's plenty of documentation of the structure of f.ex the .mod format and it's followers if you want to learn how to handle this.
But who am I to describe this? I mean, i'm just a visionary answering your question "what a new player should be able to handle". And since you're obviously not going to code the player anywhere near what i'm aiming at - I better keep still, keeping on wishing that some other coder would make something which would bring something new to the scene.
I mean, I have understood you right, haven't I? You really didn't want a serious answer to your question, nor serious comments? You wanted a load of puppets applausing your ideas, telling you that your ideas are great while you keep bragging.
Well. I'm not going to give you that. |
| |
Hate Bush
Registered: Jul 2002
Posts: 462 |
I agree with Twoflower on that. There aren't many occassions on which I'm forced to cut down the rastertime my tune uses. And if I am, there is GT 1.01, there is JCH v19, there is Ninjatracker.
What I need is flexibility, tweakability (nice word eh?), loads of features and user-friendliness (which means: as close to general tracker standard as possible - GT is unbeatable so far). Perhaps even in reverse order. :)
BTW., there is a new player/editor, coded by Asterion/Samar. Hasn't been released yet, but it is FULL of features. I talked about it with the author, and each question of mine starting with "Does it allow me to... Does it have..." Asterion replied in positive. I can't wait to see and try that tracker. |
| |
Akira
Registered: Oct 2003
Posts: 52 |
Quote: Twoflower:
cool vibrato with more usability than 'just' vibrato needs 5 nybbles. starting direction(1 bit), strenth(3 bits), width(one byte), delay_till_start(one byte)
This is a vibrato able to do cool d&b-FX and even more. Variable slides via vibrator and so on.
So don't tell wrong things some ppl have made up their minds ages ago!
Regarding rastertime: some of the most sophisticated players still need more RT than neccessary. It's a compromise between playersize, zeropage-usage, how direct you use your data, and work-scheduling inside the player!
There are two basic ways to minimize Rastertime: do a cut on FX / player-possibilities OR c0de a simple work-scheduler like atmds 3.2 has (look at rastertimes of my tunes - atmds 3.2 is a full function player with an average RTM of less than $10, max i ever seen $1a)
And a last question for twoflower: have you ever thought about how the music with all your FX will look in memory and be managed by the player? From your post it looks like NOT.
cadaver: ATMDS 3.2 has an instrument-save option, but the c0de is so hairy, that it is even hard to find the left over bugs (which appearently are there).
St0fF ... starting to ignore akira and twoflower because of lameness (sry, but i'm just honest)
Dear mr l33tn3ss, I am very sorry that my opinion has offended your superior knowledge of all things "C64 tracker" |
| |
Dane
Account closed
Registered: May 2002
Posts: 421 |
Stoff, a simple click in CSDB should give you the information that Twoflower is not a coder. He does music, however, and he knows what sort of commands are useful while tracking. Therefore, he might be wrong on how to do things technically. So what? I've listened a lot to him over the years, and trust me when I say that his opinion will be of high value when I (finally) sit down to put together my userfriendly hack of JCH's player.
You might have a different view on how to solve vibrato and such things - as do I - but his post on why we should have a player that doesn't bother with r-time was inspiring and should be read as such. Isn't it time we got a player that doesn't compromise and simply allows for basically anything, no matter the amount of mem or r-time used?
And finally, try as I may, I can't really find the parts where neither Twoflower nor Akira were offensive in this thread. I might be biased having talked a lot with the latter over the years, but right now, you're the only one who comes off in a bad way.
I wish you good luck with your player, but please don't ask for general advice or inspiration if you're not prepared to listen, ok? |
| |
dalezy
Registered: Apr 2002
Posts: 476 |
twoflower, i'd be in heaven if something like that could be realized for jch. i always wanted to be jch at least capable of letting one effect run through while another one gets added after it, like vibrato__ -> sustain/release -> __vibrato (if that made sense now =).
then, a command where i could actually change the attack and decay would also be sweet, since i tend not to waste too much instruments just for different ad-settings .. |
| |
Dane
Account closed
Registered: May 2002
Posts: 421 |
Stay cool, Ez Lady. I've started writing docs. |
| |
Frantic
Registered: Mar 2003
Posts: 1647 |
Also agree with twoflower here. It's a bit strange that the c64 lacks a really fullblown editor/player.. I'm thinking of LittleSoundDj for the Gameboy Color for example, simple fm-synthesis, speechsynthesis, midisync and of course ordinary use of the pulse/wav/noise-channels. Something like that, on the c64, would really be like a fantasy to play around with.
But, I don't agree with that such a player/editor should not compromise with anything at all. First of all, I think all "big" C64-programs have to compromise in some way or another. (If there isn't an extremely well defined purpose of the program, which is also quite simple.) There is always another possible feature to implement, or a more luxury way to implement something, at the cost of reducing something else.
And, also, I would actually find a player more useful if it wasn't eating all of the r-time, so it could in fact be used in other productions than just pure musicproductions for compos. Maybe Twoflower didn't really mean that such an editor was supposed to eat all the rastertime, but I think that would be the consequence if taking the argument literary.. There are so many possible features. Still would end up in some kind of compromises I think.
However, thumbs up for a more r-time-hungry editor with new possibilities! There's plenty to explore if going in that direction.
|
| |
Akira
Registered: Oct 2003
Posts: 52 |
Me, too, am mainly a musician, and would LOVE to have a tracker that pushes everything more to the limit at the expense of rtime that I will never utilize. LSDj is a brilliant thing and my idea for a tracker has a lot to give for musicians, but little to give to coders who want to include the stuff in productions.
But isn't there a whackload of trackers out there that do the job great while consuming little rastertime? I think that having ONE that is mainly thought for music only wouldn't hurt, and I would love to help develop it, with all the notes I have taken in a lot of time, and which I can't get to fruition because of my complete lack of C64 programming knowledge. This project in my mind is the only reason why I want to learn C64 coding,, to finally build my dedicated C64 music box machine.
BTW, Dane, in your message, when you wrote you have been talking for years with the latter, I guess you meant the former ;) |
| |
Puterman
Account closed
Registered: Jan 2002
Posts: 188 |
No, Akira, I think it was more of a freudian slip. Those erotic messages, whispered to you in your sleep, are hereby explained. |
| |
Akira
Registered: Oct 2003
Posts: 52 |
Whoah ;D |
| |
Wisdom
Registered: Dec 2001
Posts: 90 |
Calling Twoflower lame was really absurd. He's a musician (and a respected one, I might say) and he probably knows what kind of a tool might help doing his work better (or sounding cooler.)
What Twoflower put is an almost perfect capture of the things that should go into an editor like JCH's. Over all these years, the single most important feature I needed in JCH's player is the ability to set player speed lower than two (speaking for v20). That means a player updating each frame. I've done many improvements to JCH's editor/players, but I haven't found the time to do this one (in fact, when I was to do it, I stopped being an "active" scener, around 1996.) I had done a player myself, which was to be integrated into JCH's editor, but that didn't come true, either.
So, what needs to be done, from a musician's perspective, is a player that updates each frame and gives all the nice effects etc all together, without worrying about raster-time usage. Who cares about raster-time, when he's composing for a music compo? Or just for the pleasure of composing for SID? If I'm to consider that a tune of mine might be used in scene productions, I would rather go use NP v19 or John Player or something similar.
So, basically, there are two types of players need to be done:
1) A player giving a nice set of features, while being very low on raster-time usage. (This is done, several times.)
2) A player boasting to have most of the really useful features out there and have ultimate speed in updating. (This is something not available yet, at least not for public.)
Struggling for anything other than these two is probably futile, from a musician's perspective. It might be of use for a coder to masturbate and then brag about.
I already want to release all my improved or written-from-scratch JCH stuff for years (some of the musicians out there already know this from our IRC sessions.) Real life didn't permit me to do that until now. But I'm really eager to do it. As Dane also works on his improvements (and a few others, AFAIK, like DJB of BM) for JCH's, maybe we all should come together to form a work group that will manage to put the ultimate JCH's editor/player out. That would save us from doing the same things and all those scattered versions with different sets of feaures. I don't know what you guys would think about this.
|
| |
Dane
Account closed
Registered: May 2002
Posts: 421 |
It's a good idea. Get in touch with me and I'll brief you with what I've done so far and vice versa. We can take it from there. |
| |
St0fF
Registered: Oct 2002
Posts: 40 |
Twoflower: SORRY!!!
after a few years i think your ideas ain't that bad - nope, they're great! but i still am a democoder (well i coded more tools than FX, but who cares..), who thinks about the spare time for FX after the music was played in multi-speed. But I learned - because... how many ppl use atmds? just me - that a tracker needs to be done for the musician, not for the coder. And guess what: i didn't like any of my recently reeased tunes myself. the last one I liked myself was happyness 2002 ...
so sorry again! |
| |
SIDWAVE
Account closed
Registered: Apr 2002
Posts: 2238 |
St0ff: what you really need to do, is to make the sounds independant. So a sound has all in it, when saved/loaded.
This will allow the swapping of sounds between composers, the #1 reason soundtracker/protracker etc. became so popular.
This way, it will be possible to build a sound-library.
Who cares about democoders ? :-)
They can already do so much, so adding another 20 rasterlines wouldn't hurt. They just have to get better!
So far, coders sacrificed most of memory for large IFLI pics, now it's time to sacrifice raster for ultimate SID player!
|
| |
ne7
Account closed
Registered: Jul 2004
Posts: 17 |
I definately agree 100% with Twoflower and Dane's points here - i would absolutely LOVE a tracker that really used the C=64 to the brink for just music. would be a fab tool for gigs and music making in general (using the c64 as a fat sounding synth like some use the gameboy) it would simply be fantastic =)
|
| |
Soren
Registered: Dec 2001
Posts: |
What I want from a player:
64 instruments
ADSR settings
2 wave+freq tables (2*(256+256) bytes)(END and JMP commands included ofcourse) (these have to be able to handle both note-freqs (values 00 to $5F) and high-/drum-freqs (simply take the freq byte and store it in the freq-highbyte address.
Arpeggio-speed, set-able for each instrument.
1 pulse program table (not just the usual boring way of doing simple pulse programs, but a system that works more or less like the JCH-system.
filtertype + resonance for each instrument
1 filter program table (again like in the pulseprogram, you need to be able to do all kinds of different speeds, widths and having time-settings for these)
Also you need a jump command for both pulse+filterprograms, for jumping around in the tables to do more interesting stuff.
1 additional filter program that is being added to the normal filter program, in order to be able to make more interesting filters with more variation etc.
A must is also the Continuous pulse/filter, so you can start a pulseprogram with 1 instrument and let it move along in the program it's set to, no matter if you set new notes etc.
detune settings for each instrument
different hard restart settings that you can change for each instrument (you need to be able to switch hard restart off atleast).
Also you can do nice things if you skip oscillator reset (a nice thing for doing really soft leads, like Tim Follin's flute leads)
the track+sequence system should also be quite simple, like the JCH system, but the "Insert command" table should have more advanced commands... like commands that can do several things. I won't reveal what commands I have, just yet, you'll have to wait with that ;-) (have to keep some secrets to myself ;-)
I'd say atleast 128 sequences and 3 tracks of 256 byte.
minimum a 2-byte tempo-table, so you can do shuffle stuff. GRG's SDI has a very cool system that allows you to do it as you like, with more than just 2 bytes.
Well, all this and more is already in my newest player ;-)
working a bit on the userfriendly editor for it when I have the time.
But I don't want to have more features than I need it my players, no need to waste memory+rastertime on more than is needed. |
| |
HCL
Registered: Feb 2003
Posts: 727 |
@Jeff: Sounds really promising!! But you also mention the major problem in the end: "But I don't want to have more features than I need". Everyone seems to have their own ideas of what needs to be included and what should be left out. So everyone starts coding their own custom player which will be used by noone but themselves (i'm there too). E.g. i want multispeed for the irascible pulse it gives, will you include that :)?
However don't get me wrong. I'd really like to encourage you to work on your player. |
| |
Ninja
Registered: Jan 2002
Posts: 411 |
Or make the players + editors open source, so anyone can do as wanted. |
| |
St0fF
Registered: Oct 2002
Posts: 40 |
@ninjadrm: i don't see your point - changing an editor to completely different music-mem-layout could be even harder than rewriting an editor ...
I dont think i could use Jeffs editor to edit atmds-musics... |
| |
Soren
Registered: Dec 2001
Posts: |
HCL: Yeah we all have our different needs. I am mainly doing my new player(s)+editor for my own needs, but if other people find them usable, that's just great.
Sorry, didn't quite understand that "irascible pulse..." thing you mentioned.
But as you know yourself it's also very satisfying to code players on your own, instead of using other people's tools.
Ninja: I don't plan to make my player+editor open source, as I want to have the total control of my own tools, so strange modded versions won't be around and possibly not work together with the tools I am doing. :-)
St0fF: I just try to keep things as simple as possible. I don't find the need of doing "FastTracker 2"-like patterns as they take too many bytes - I simply try to keep it in the wellknown c64 style, like JCH's editor, but with extra features ofcourse. But we all have different needs/taste. Best wishes with your work on your tracker :-) |
| |
Bamu®
Account closed
Registered: May 2005
Posts: 1332 |
Interesting thread here ... :D
It seems that nothing is released so far...
Btw.
@'everyone who is interested'
Well, personally I don't like JCH's style (neither SDI-style) since it isn't very optimal for ME. I always will prefer "FastTracker 2" style.
Sure, patterns take a lot of memory, but WHO CARES? For people which mainly compose for own pleasure memory/rastertime doesn't matter. :P
I like simple & intuitive interfaces & easy handling. (Of course, and a GOOD hardrestart)
One of my BIGGEST dislikes of common c64-editors/trackers is that you have to enter note-numbers always by hand. This is everything but not flexible.
Tons of cryptic cmd's are useless, since NOBODY will be able to use them.
... just my opinion :) |
| |
Linus
Registered: Jun 2004
Posts: 639 |
i think everybody got your preferences now. what are you after?
ever thought about giving vst-related music making a try? after all it's much easier to use contemporary pc-trackers/sequencers without 'tons of cryptic commands', channel limitations, 'bad' hard-restart etc. plus there are millions of presets available, no need to bother with wavetable programming and improper siddump outputs.
|
| |
cadaver
Registered: Feb 2002
Posts: 1160 |
Improper siddump output? Where? |
| |
TNT
Account closed
Registered: Oct 2004
Posts: 189 |
Quoting nataTons of cryptic cmd's are useless, since NOBODY will be able to use them.
... just my opinion :)
You just called a lot of talented C64 musicians nobodies. But that's just your opinion, right? |
| |
Bamu®
Account closed
Registered: May 2005
Posts: 1332 |
Quote: Quoting nataTons of cryptic cmd's are useless, since NOBODY will be able to use them.
... just my opinion :)
You just called a lot of talented C64 musicians nobodies. But that's just your opinion, right?
I don't think that I have meant it in that way. |
