|
|
Expert
Posts: 512
Location: Netherlands | grab it here!
All made with Revisit. Mixed & mastered in Vegas (24 tracks, imagine the time it took to export to waves, in real-time mode, due Loopbe30)
Large <30hz speakers recommended, it's a pandemonium of loudness at times.. :-) |
|
| |
|
Veteran
Posts: 102
Location: Austria | great! very impressive composition in an outstanding quality  i don't listen much to orchestral music, but i notice some of the very little details and am sure it took many, many hours to finish that one... btw what happened to the "pirate-theme-track" you posted some time ago...did you ever finish that one?
greetings,
fegi |
|
| |
|
Expert
Posts: 512
Location: Netherlands | ^_^
The pirate tune is just somewhere on my HD. Back then I created a fully orchestral setup, made out of 10 fully loaded Halions. But back then I didn't realize that on my 4GB PC I had only about 1.5GB for samples, due XP32. So this set was usually too big, resulting in not loading back completely. One has to manually load those banks again. In short, the project was a mess for the PC. This Galaxy tune uses dedicated samples, e.g. only those I really need, and it tops somewhere around 4 Halions, with 2 or 3 as average for the whole thing.
btw, just dragging/dropping all the Galaxy tracks into Vegas took half an hour already.., and it required about 6 hours to export all tracks as wav.. to give you an impression about the scale of this sucker! :P
oh and the spam-flood is really getting annoying recently  |
|
| |
|
Developer
Posts: 746
Location: England | Excellent tune!!!
As a reward  : I've implemented forum code that requires Guest posters to enter a random 6 digit number from a ASP-supplied image. Hopefully, this will bring an end to the spam posts.
On the reViSiT front, I've implemented basic Surround Sound already. So far, I've added: - A Y-axis to compliment the existing X-axis panning (both X and Y values are shown in the new pan editing mode).
- A Txx effect to control surround sound theta (azimuth). Effectively a rotation effect, which will take the X and Y position and rotate is by xx (00h = no rotation, 40h = 90 degrees, 80h = 180 degrees, etc.)
So, I've had sound zooming all over the place. However, there's still a lot to be done. Notably, the increase in channels (from 2 to 5.1) means CPU usage is up, so I'm going to look into any feasible optimisations. Also, I've started planning for the multiple, assignable outputs and routing system. This has presented a few logistical problems - not least with how to design the interface so that the user has a clue what's going on! On the publicity front (as alluded to here), reViSiT has been selected in the Best Tracker category, in Computer Music magazine's Top 50 Freeware Special Issue, which features a review of the software, a couple of tutorials and even a mugshot of yours truly. Also, by all accounts, the next issue's cover story will be on trackers and will feature reViSiT, so stay tuned! All the best,
Chris |
|
| |
|
Expert
Posts: 512
Location: Netherlands | Perhaps you should give 'm the link to that tune, just in case they think a tracker is only good for those early 90's .mod files they hear in some Amiga emulator :P
I've met several ppl (including the commite of my study back then (for lack of a better word.. those ppl you talk to who decide whether you may pass or not)) who had this idea. Back then I was using IT2, and I demo'd them some music. The actually found it hard to believe how I did things, and when I told 'em it was like a 64channel modfile they were like "O_O WTF?". The same thing happened in the first months of the actual study. No-one could understand what I was doing, no-one would believe it was smart what I was doing (I've heard teachers preach about it!). So, there's a huge world to win for tracking, but the old stigmas have to go first, and I think tracking still has some of those stigmas (underground-only, only for dance/house etc.). |
|
| |
|
Developer
Posts: 746
Location: England | Trackers are definitely coming back, and gaining more credibility than they ever had before, thanks to improved sonic quality and professional feature sets.
Trackers have already got a foothold in the press, with Computer Music magazine acknowledging their popularity and importance. Also, I'm writing an article for a research journal that analyses trackers from a cognitive psychology standpoint, and tries to nail down why (and highlight how) - in scientific terms - trackers can afford a faster, more fluid creative process compared to other computer music methods. Naturally, the article will be objective and also identify the weeknesses of tracking, but hopefully it can elevate the method's status and fervour discussion at a higher level than "underground" demo parties.
The biggest hurdle for tracking was always ignorance, and in the past there was a whole lot to be ignorant about - you needed to be a nerd to even want to learn how to write music with a computer keyboard and something that looked like a speadsheet. Now, not only have the interfaces moved on, but so has the user. The computer musician is ever more adventurous, taking computer literacy for granted, having grown up with computers.
I wonder how many of today's studio owners and composers got their first sample of music production from a tracker in their childhood? All they really need is a little temptation, say in the form of a pluggable tracker, to get them to 'revisit' those happy days...
Chris  |
|
| |
|
Expert
Posts: 512
Location: Netherlands | There are actually 2 immediate gaps left, I know I've mentioned them before, and you said something about v1, rather than some beta version, but I still try ^_^
- naming of a channel is of utter importance, I've no clue how large your own tracks get to be, but that Galaxy track goes all the way from the left to the right, if you get my point. It's a bit annoying to move to previous patterns just to see what note was on that channel. I can't imagine it's that much work? It's an array of 64 strings I'd say, or a string field per channel (if you have a channel class and declared 64 of 'em, which is prolly what you did)
- keyswitching is a standard method in libraries to switch articulations, at least in those libraries I use, which are industry standard libs. I rather have an fx-command to hit a (switch)key than to have a dedicated channel doing that. Imagine the strings, 5 lines, so that's 5 channels for notes and 5 for switchkeys. This totals 10 channels out of 64 channels, just for the strings. For a harp I usually reserve a channel or 5, for woodwinds I usually have about 8..10 channels, 4 instruments with switchkeys, and sometimes some more channels in case I have for ex. 3 flutes playing a chord. That's basic woodwinds then, excluding contrabassoon, piccolo, altoflute and bassflute. Brass, the same story: tuba, trombones, trumpet, horn(s), that's also easily 12 channels. Some chromatic percussion (xylophone, glockenspiel, vibraphone etc.) ~5 channels. Percussion section, up to 6, including timpani. So without using divider channels I'm at ~43 already, Add some 8 channels for a piano, and 4..5 for a choir and we're at 56 already. And then it's all about praying that you won't need more than that. It's those switchkeys that consume channels, but I can't afford to ignore them, in the worst case I'm switching keys all the way!
So the ultimate solution would be to have one effect doubling as note entry with the effect parameter as notenumber. The best option would of course be an extra note channel, but I can see how that's all too drastic atm.
It might be hard to imagine, but having all these notes and switchkeys cluttered around a huge 64-channel page is truly messy. It's a bit the same feeling someone has when looking back on procedural programming, while sitting in an OO world. |
|
| |
|
Developer
Posts: 746
Location: England | CS_TBL - 2007-04-05 9:39 PM
- naming of a channel is of utter importance, I've no clue how large your own tracks get to be, but that Galaxy track goes all the way from the left to the right, if you get my point. It's a bit annoying to move to previous patterns just to see what note was on that channel. I can't imagine it's that much work? It's an array of 64 strings I'd say, or a string field per channel (if you have a channel class and declared 64 of 'em, which is prolly what you did)
Indeed, reViSiT already has your array of 64 strings representing channel names. But it's not that simple - you've forgot to take into account the interface code, planning and graphics required to allow the user to set the name. Actually coding it isn't hard, but deciding how to do it and actually implementing it takes time if I want to do it right, and it's just one of a dozen other features that aren't "that much work".The most sensible place for such a setting is the Order List (F11), where the initial channel variables are set. As it happens, the surround sound support will require this interface to be re-written anyway, so I'd already planned to take the opportunity to add channel names and colour coding. CS_TBL - 2007-04-05 9:39 PM
- keyswitching is a standard method in libraries to switch articulations, at least in those libraries I use, which are industry standard libs. I rather have an fx-command to hit a (switch)key than to have a dedicated channel doing that. Imagine the strings, 5 lines, so that's 5 channels for notes and 5 for switchkeys. This totals 10 channels out of 64 channels, just for the strings. For a harp I usually reserve a channel or 5, for woodwinds I usually have about 8..10 channels, 4 instruments with switchkeys, and sometimes some more channels in case I have for ex. 3 flutes playing a chord. That's basic woodwinds then, excluding contrabassoon, piccolo, altoflute and bassflute. Brass, the same story: tuba, trombones, trumpet, horn(s), that's also easily 12 channels. Some chromatic percussion (xylophone, glockenspiel, vibraphone etc.) ~5 channels. Percussion section, up to 6, including timpani. So without using divider channels I'm at ~43 already, Add some 8 channels for a piano, and 4..5 for a choir and we're at 56 already. And then it's all about praying that you won't need more than that. It's those switchkeys that consume channels, but I can't afford to ignore them, in the worst case I'm switching keys all the way!
So the ultimate solution would be to have one effect doubling as note entry with the effect parameter as notenumber. The best option would of course be an extra note channel, but I can see how that's all too drastic atm.
It might be hard to imagine, but having all these notes and switchkeys cluttered around a huge 64-channel page is truly messy. It's a bit the same feeling someone has when looking back on procedural programming, while sitting in an OO world. Keyswitching has been discussed (debated) before, and all my original arguments still stand. However, since it was relatively easy for me to add Keyswitching (Note Emulation) as an extra MIDI effect, I have done so (it will appear at the end of the list in the next release). Chris |
|
| |
|
Expert
Posts: 512
Location: Netherlands | great! A minor detail: when is the fx-column processed? before or after the normal notecell is processed? For keyswitching, the fx-column needs to processed first of course, and I'm not sure about the order now. (with 'processed' I of course mean: when it's being sent away as MIDI msg)
Regarding tracktitles: Are those strings already stored in the revisit xml fileformat somewhere? I wouldn't mind manually changing them until there's official editing of those titles. Heck, I could even see myself doing a template for a typical orchestra.
Edited by CS_TBL 2007-04-06 5:18 PM
|
|
| |
|
Developer
Posts: 746
Location: England | The processing of the effect column can take place at different times, depending on the effect. For example, Note Delays (SDx) are processed before the row, Sample Offsets (Oxx) on the row, and slides (Dxx, Exx, etc.) after the row. MIDI effects work slightly differently, as all MIDI messages are queued before execution in time with the audio. As such, MIDI Notes are processed first, but MIDI effects (including keyswitching) are automatically placed at the head of the queue, and should thus will actually be received by the MIDI device before the note is triggered - as you would want them to be.
As regards channel naming, the arrays are part of the program, but are not saved or loaded in the current release. As of today, however, the naming feature is now complete and will be present in the next release.
Chris |
|
| |
|
Expert
Posts: 512
Location: Netherlands | yay yay yay ^2
They may be small steps regarding code, but giant leaps for composing workflow!  |
|
| |
New tune!
