Newsgroups: comp.sys.cbm,alt.c64 Subject: Re: Iseq music composition program released Summary: Expires: References: Sender: Followup-To: Distribution: Organization: Southwest Cyberport Keywords: Cc: Hola Agemixer :) In article , Agemixer wrote: > >On 10 Jun 2002, Steve Judd wrote: > >Referring to the docs, it seems to be missing atleast some flexible >wavelist/arpeggio, and seems to be replaced with 'fixf' feature. For >example, how could i do a continuous bass sound sequence like this can >be done in Iseq:? > >Wave trp+ > 51 0c > 41 0c > 41 0c > 41(0) 00 > 41(0) 00 > 41(0) 00 > 41(0) 00 > 40 00 > 40 00 > 40 00 Well, I'm not sure what the trp+ is, but I assume the "Wave" settings are $d404 settings. In Iseq, I'd just create a sequence of length 8 and enter those values (although I wouldn't use $51 :) -- when I used mixed waveforms in the past they didn't work on lots of SIDs). Instead of a program with a set of built-in features, I've had this sort-of vision of a flexible set of tools that let you manipulate SID and compose music -- a "shell" with a set of musical building blocks that you could define and combine into anything you wanted, that let you control exactly what happens and give you total control over SID and the player's behavior (not a programming language; just a set of tools and a framework). That motivated a lot of Iseq. Any music player can only write to SID every time it's called. In iseq, you specify exactly what gets written on each call. If you want to modify the frequency register, you do it; same for the filters, ASDR, waveforms, etc.; all registers are available to each instrument. The goal is to give you full control over what gets written to SID. In addition to plain sequences -- which can be written continuously or just once -- there are also "modulators", for example ramps, which can go from A to B step C, and adders, which can add sequences of values. The "fixf" thingie is something different. fixf just restores the frequency after a little bit -- for example, the bass+hihat example instrument sets the waveform to noise, then triangle, then pulse; meanwhile, the frequency needs to be high for the first two player calls, then restored to its original frequency. That is: 1st player call: waveform=$81 freq=$a000 (or whatever) 2nd player call: waveform=$11 freq=$a000 3rd player call: waveform=$41 freq=original value fixf restores the frequency, that's all. All of these are meant to be tools, for manipulating SID. They are actually compiled into the player during editing, and this makes it very easy to add more. Anything you want, to manipulate SID, can potentially be added in. Arpeggios are in there -- ctrl-a from the instrument editor brings up the arpeggio editor. Arpeggios can be any length and speed, can have positive and negative offsets, and can either run continuously or one-shot. >And an another issue, i didn't find a single word of "slide", "glide", >"tie", or even "vibrato" effects from the docs, so i guess they are >completely missing. Actually those are very important for the quality of >the tune sounds and enjoyability... though most of those aren't >made too well in some very known editors around, i had to replace the >glitching glide sounds with my own methods with wavelists + ties, and even >vibratos if the editor just made it possible. Well, like a lot of things I probably was dumb and didn't mention it in the docs, but part of the Iseq philosophy of "you control the SID" is that it doesn't have built-in effects. Instead, it tries to provide the tools you need to build your own effects. It tries to not limit you to whatever effect is built into the player. So, for example, the instrument editor has a thingie called "frq+". With frq+, values are added to the current frequency. So if you want a vibrato, you enter a set of frq+ values to increase and decrease the frequency, and loop it continuously: frq+ 0100 0200 0100 0000 ff00 fe00 ff00 0000 On the downside, it's not "proportional" -- you wouldn't use the same modulations at low and high frequencies. On the plus side, you get to specify exactly what you want, and combine it with stuff to make more complex effects; for example, it's easy to, say, combine a vibrato with a rising frequency, or make little ornaments for notes, or an 'asymmetric' vibrato -- anything you can think of. This is also the idea for slides and glides -- again, the idea was that they're not built in, but the tools are there to make them. They can also be done using the arpeggio editor. Since this is kind-of a crappy way of implementing them, philosophical purity of not having any built-in fx may be abandoned in a future release :). But from your descriptions above, it sounds like building your own slides was necessary anyways. So the question is: is there a _better_ way of implementing slides, a way which lets you, the composer, control exactly what happens? I couldn't think of one, but I'm very open to ideas. Ties are built into the player. Players typically do things automatically for the composer -- restart instruments, toggle gates, etc. With the aim of giving control to the composer, Iseq has switches for all those things. You can turn gate toggling on/off, restarts on/off, and so on. There are also two special notes, "hold" (continue previous note) and "rest" (zero frequency). One way to do a tie is to turn off instrument restarts and hold the note; another way is to just define a longer duration! Slurs and such are similar -- just turn off the parts that reset instruments. It makes the player a little bulkier and less efficient, but again, I don't want the player to automatically assume what you want and do stuff for you -- I want you to have the abilitiy to control the behavior exactly. >... >more common method that F1/F3/F5/F7 = play/stop/cont/f.forward >(DMC-styled) or something similiar. The idea is to get rid of multiple >keypresses for most common keypresses. But it is also a good idea to hide >f.e. clear track, clear instruments undo commands and things like this, >behind any press-together of either SHIFT, CBM or CTRL. For example, Home >... >And why not implementing different keysets (DMC-like, JCH-like) to improve >one's get-in-touch. Atleast I planned that for my tracker project years >ago. Good idea. Thanks for the suggestions/tips; I'll keep them in mind! I tried to make common keypresses single-key -- notes, durations, etc. -- and group other functions together under the ctrl-keys. I just couldn't stomach using something like "m" and "n" for "turn gate toggle off/on". I think I would have ran out of keys anyways. >I remember the Voicetracker times, when you HAD to type the whole >C#4.1f command to get the note and a duration for it. Argh! :) Yeah, that's what happened in my first player(s) (blahtune/tunesmith). It's not horrible, but it sure gets old fast. I think Iseq does a reasonable job of getting around this -- just changing durations when necessary -- but kind-of like a tracker I'm concerned that it gets me thinking about the composition in rigid intervals, i.e. every note becomes a 4/4 kind of note. (If that makes any sense :). >> >With first tests it hungs when adjusting the speed >> >> I'm sorry, could you be more specific? (If there's a bug, I'll need more >> information). > >When you press cbm +/- some times (during playing) it reserves a lot of >rastertime and plays the tune in a high speed, but pressing any keys >has no effect. Hmmm. cbm+ doubles the playback speed, while cbm- halves it. If cbm+ is pressed too many times things will get out of control -- IRQs start happening faster than they can be acknowledged. But keys should still work. I'll have a look (and try to break it). >> >and the loader doesn't seem to work with Action Replay cartridge. >> >> This is a strange thing, and the fault of AR. The "loader" is just the kernal >> LOAD routine -- totally standard. For some reason AR seems to get confused, >> maybe when the call to LOAD is done from bank 2. > >Ok. (It may be an emulator bug too, sorry.) No, it's an AR thing, and you're absolutely right. I was stupid to not have a fix in place, since everyone and their brother uses AR. Programs that don't work with AR are programs that don't get run! >> Using the CIA timers _removes_ restrictions. > >It _does_ the restrictions, if one made a tune with CIA timing, and i >need to use it with a fullscreen FLI demo or raster timing stuff :) Well, this is another place where I was stupid and left some important information out of the manual. Here's what I should have said: just set the first tempo value to $4cc7 (using ctrl-t) and it will behave just like a VIC interrupt. $4cc7 is the PAL setting; $42c6 is the normal NTSC setting, and $417f is for old NTSC R56A VICs (64 cycles per line). Also, when you clear a tune using shift-clear, the code checks whether the machine is PAL or NTSC and _should_ set the value appropriately -- another thing left out of the docs. Bleah. Anyways, the bottom line is that you can make it work just like a normal VIC interrupt -- you're just not limited to a VIC interrupt. >Hmm, a so-called 100% cover of Commando tune by Rob Hubbard could do >fine :) > >/hvsc/hvsids-4.6/Hubbard_Rob/Commando.sid >/hvsc/hvsids-4.6/VARIOUS/A-F/Agemixer/Commando_Remix.sid > >which i covered with DMC 4.0B, this editor is easy but one of >hardest ones for covering anything well. :) Heh, cool. OK, I'll take you up on it :). But you'll have to describe the instruments to me -- I'm pretty clueless as to duplicating instruments I haven't done before. (We can do this in email). That is, if this is a test of my abilities -- well, I lose, I can do the notes from memory but I don't know how to make his instruments. But if it's a test of iseq's abilities, well, some information would be most helpful :). >Most of the judgement is based on first experience and feeling. >But now you know atleast one who even bothered to test the editor =) Yep, fair enough, and I would surely have a similar reaction, if not worse; if I can't figure something out quickly I usually put the program aside, and I should have put more work into easing into this one. Oh well. As to the second, what makes it REALLY rare is that you not only tried the program, but made COMMENTS on it! :) (That _never_ happens!) >Those horizontally placed notes in sequences in iseq is very strange for >music. Not that the common oldie note and delay staves with G-key are >also... :) Well, that's a funny thing. We read books left to right, and sheet music left to right. There's more columns than rows on the screen, too. So I began to wonder why 64 tunes are written like Chinese script. One reason is of course that if the information is "wide", more of it fits in columns. And I learned another reason -- vertical stacking is a lot easier to code than horizontal (especially with variable-width fields)! But Iseq fits, what, 12 "tracks" on the screen at a time by using rows, and more notes are visible at a time. You can see at a glance which are used, which are left, which parts go where. It's taken me some getting used to, too, but, well, I actually like it! >It is also missing the on-screen octave information, that is important to >see the current playing note octave. Well.... this is another one that got to bugging me. Tunesmith displays note, octave, and duration on the screen, and I realized that I never found the octave/duration information useful, but instead spent all my time single-stepping to find my place in the tune. Iseq displays the current octave at the top of the screen, and displays the octave in the "long" description of the note under the cursor. I did try putting the octave information in with the note, but decided that A B C# B C# A D was a lot cleaner looking than A-4 B-4 C#-4 B-4 C#-4 oops ran out of screen room so it went into the long description instead (at the bottom of the screen). >A some kind of sequence position is necessary for editing, too. Hey, great idea :). >I know the feeling, there is a lot of 'unfinished' editors around that >either weren't flexible enough, or, the music routines took a lot of >rastertime... So i decided to start my own tracker project, meanwhile a >lot of people wanted to kill my project "aren't there already enough of >good trackers around yet", "This will become nothing anyway, everybody >already uses their own music players", "This kind of editor is already >being under construction, see this link blahblah.." and mumblings like >that. Bah. That's Bull. I totally think you should write your own player. As you say, current programs do _not_ do everything they can or should do. Besides, you're an experienced and high quality composer, so why should you have to depend on others for your composition needs, especially when those needs aren't being met? Now, if it means you'll have to stop composing for a while and/or get bogged down in a bunch of coding, well, forget it -- talk some coder info adding the features you want :). Or maybe someone has released some source code that can be modified. Otherwise, there's always room for more, new programs. That's what keeps the C= going, and if it makes you a more productive composer then where's the problem? (I almost hate to mention it, but you can always tell ME what features you'd like to see :). Anyways, I really do appreciate the comments, and the chance to defend poor little iseq (actually, it's something like 70 blocks of code -- not tables, graphics, music, and code; just code -- which is really humongous). Further comments, good or bad, are unexpected but always welcome :). I rarely read comp.sys.cbm though, so maybe email is better. And Agemixer: get busy on the Ultimate Tracker! :) cu, -Steve