|
|
Developer
Posts: 746
  
Location: England | Hi Everyone, It is my pleasure to deliver reViSiT v0.92 Beta, featuring numerous updates and improvements, such as:
- Audio Performance Improvements
Hours of code profiling and optimizing have allowed me to squeeze a little more out of the processor – up to a 25% drop in processor load, depending on your configuration.
- Audio Quality Improvements
Users should find notes are better defined, after I toned down the effect of the no-click filter. The filter should still prevent clicks, but without smoothing the dynamics of the music. Let me know what you think!
- Non-Destructive Save Mechanism (Ctrl+S)
reViSiT now offers a quick-save method that allows you to save a module without overwriting the previous version. When you hit Ctrl+S, reViSiT will make a copy of the module data already in the existing file and timestamp it, before saving the new data. Note, that samples will still be overwritten. By retaining the old module, you’ll have the option to go back to an earlier stage in the piece. And since there is little reason not to hit Ctrl+S frequently, you’ll minimise any lost data should the computer through a wobbly. To load previous versions, open the zip file, find the file with the appropriate timestamp, unzip it, rename it “Module.xml” and put it back in the zip file. Note: Remember to backup your existing “Module.xml”, if you think you might still want it! In the future, I’ll add an interface allowing you to choose from the different versions in a loaded file, and possibly introduce an Auto-Save feature.
- New/Clear Function (Ctrl+N)
Hitting Ctrl+N will prompt you before clearing all the samples, instruments and patterns, so that you can start afresh.
- Minor bug fixes
A few niggles that escaped v0.91’s bug cull have been dealt with: help popups no longer stray off the side of the screen (and won’t be split across multiple monitors); Pattern Follow has moved back to Ctrl+F; Note Offs are output upon insertion.
- [ Professional Edition Update ]
In parallel with this public release, the second Professional Edition is being made available to selected testers, featuring a full feature-set, including both surround sound and assignable outputs. v0.92 Pro adds several ways of dynamically grouping and splitting your music over multiple output busses, to allow flexible post-processing in the host. Up to 16 separate busses (each affording up to 5.1 audio) can be delivered to dedicated “reBUS” VST effects plugins, which can be loaded as insert or send effects anywhere in the VST host. Send individual channels, instruments or samples - even specific notes or phrases, using the new S0x (Set Output Bus) pattern effect.
For full details and many more changes, please read the release notes and download reViSiT v0.92 Beta from http://www.nashnet.co.uk/english/revisit/download.htm. If anyone has any questions, feel free to pose them on the forum, and I’ll try to answer you as quickly as possible. For more information, see the reViSiT website @ http://revisit.nashnet.co.uk. Enjoy! All the best,
Chris
|
|
| |
|
Expert
Posts: 512
Location: Netherlands | Will test, but not until sunday, have some accordion-ensemble performance I'm doing light&sound for, these days..
I just got a silly tho interesting idea btw: If you could somehow keep track of the time someone spends on creating a tune, by 'recording' (or something) editing/destructive keypresses, you could see how long it took to create a song. You could for instance store the latest date+time somewhere, including closing/starting-up revisit. Upon each new destructive keypress (add a note, copy/paste etc.) you compare the old date/time with the new date/time, add the result to the total time, the current time will become the 'old time' and the whole process starts again.
I could say some tune took 6 hours to make, but was it really 6 hours? Or was it 2 hours and 4 hours of listening? I estimate that the results will speak for tracking, big time. I made a slightly deformed version of Once Upon A Time In The West for this accordion thing (some kinda intro song, I'll dump it in the USER SONGS section later), which I did in 6 hours. It would be very nice if you could say to someone who isn't familiar with tracking: "Look, hear what you can do in only 2..3 hours!". |
|
| |
|
Expert
Posts: 512
Location: Netherlands | * hmm.. why did you restore the note-off upon === thing again? It was perfect the way it used to be..  I guess you never enter note-offs during playback..
* project I made with the previous version won't play. Hitting keys in the instrument screen does play the instrument, but song and patterns won't be played. It does work with a new project tho.
* Upon reload, cubase complains about changed channel configuration, used to be 3 stereo, now 1 5.1 (or something), is that related to ^ ?
* Will test more after diner, but with the previous version I got this idea: upon [F8], also damp the sustain controller, so that sustained notes (pianos e.g.) won't go on after you press [F8]. Dunno if this functionality should be generic for each specific controller or just for the sustain controller.. for you to decide.. |
|
| |
|
Expert
Posts: 512
Location: Netherlands | detail on point 2: I got it working by saving the rev file, wipe the rev instance (but not my VSTi's)1, reload the rev instance, reload the rev song. But that's ofcoz only a workaround for a bug..
Another thing, that just got my attention: can you make the major row highlighters also visible within a block?
Edited by CS_TBL 2007-11-30 6:49 PM
|
|
| |
|
Expert
Posts: 512
Location: Netherlands | Was ctrl-F2 supposed to apply the copied pattern length/highlighters? Because it does nothing! Atm I'll be required to use the previous version :/ |
|
| |
|
Veteran
Posts: 102
Location: Austria | every time i reopen the project im currently working on i have === in the first row of the order list instead of 000.
this happens also, when i resave the project. |
|
| |
|
Developer
Posts: 746
Location: England | Thanks for the feedback, guys. CS_TBL: * hmm.. why did you restore the note-off upon === thing again? It was perfect the way it used to be.. I guess you never enter note-offs during playback..
Because it was requested. It seems there are some situations where you want it, and some where you don't. I'll think about making it toggleable. * project I made with the previous version won't play. Hitting keys in the instrument screen does play the instrument, but song and patterns won't be played. It does work with a new project tho.
* Upon reload, cubase complains about changed channel configuration, used to be 3 stereo, now 1 5.1 (or something), is that related to ^ ?
I believe these are related, but they not a reViSiT bug. The Pro version's output did change to 1 x 5.1 in v0.92 and that might confuse Cubase when loading old projects - it no longer knows where to route the audio channels, given the changed configuration. With no audio connections, the VST host doesn't send the necessary time information and thus the song can't be played. However, it shouldn't be necessary to scrub and reload the reViSiT instance - you should be able to simply reassign the connections. I thought you were given this opportunity at the point when it initially complains, but you might have to go to VST Connections, or whatever it is called in Cubase 4. Future versions of reViSiT should retain the same output configuration, so this should only be an issue once - when you upgrade from v0.91 to v0.92. * Will test more after diner, but with the previous version I got this idea: upon [F8], also damp the sustain controller, so that sustained notes (pianos e.g.) won't go on after you press [F8]. Dunno if this functionality should be generic for each specific controller or just for the sustain controller.. for you to decide..
I'll think about it. It strikes me as odd that the synthesizers in question don't have the sense to end sustained notes when an All Notes Off / All Sound Off message is received. 'Might be able to add a Reset All Controllers message, though. * Another thing, that just got my attention: can you make the major row highlighters also visible within a block?
Possibly - however, I've got to be a little miserly with colours in the pattern, as I'm only using 4-bit colour (16 colours) to save on memory usage. Was ctrl-F2 supposed to apply the copied pattern length/highlighters? Because it does nothing! Atm I'll be required to use the previous version :/
Ctrl+F2 applies the settings last applied in the Pattern Options screen, and does not relate to the clipboard. However, there are other features that might help. From the release notes of v0.91: [ADD] Apply last Pattern Options feature (Ctrl+F2)
[ADD] Alt-O*2 overwrites + extends pattern (if required)
[ADD] Shift-Alt-O copies highlighting from clipboard, without copying data.
[ADD] Shift-Alt-O*2 overwrites highlighting and extends pattern using clipboard, without copying data. Note that the clipboard features will only extend (not shrink) the current pattern if you overwrite the clipboard with these last three functions. Let me know if you're still having problems. Fegi: every time i reopen the project im currently working on i have === in the first row of the order list instead of 000.
I think I noticed this in a file you sent over, but couldn't find a problem in the code, so assumed it had been entered intentionally. I'll investigate further. Chris |
|
| |
|
Expert
Posts: 512
Location: Netherlands | It would be more easier -and definitely high on the prio list if it was up to me- if there was a generic multiple pattern copy mechanism somewhere. As in:
a copy function with 3 arguments: startpattern, destpattern, patterncount, which copies patterndata, highlighters and length. Just imagine what it currently takes to copy 8 patterns starting from '2' to '32' and on, where each pattern has a different length.
(and the earlier mentioned pattern reorder, see somewhere else on the forum -recently- :P) |
|
| |
|
Developer
Posts: 746
Location: England | Yeah, I can see how that would be useful. I'm not sure I'm crazy about the dialog idea, but I know what you're driving at, and I'll give it some thought.
Chris |
|
| |
|
Expert
Posts: 512
Location: Netherlands | Well, dialog.. I wouldn't see how else, unless you like hackyness, like going to the start pattern, press a rememberA shortcut, go to the last pattern to copy, press a rememberB shortcut, go to the dest.pattern and press a pasteArea shortcut.
One thing you may keep in mind is whether you're fond of the pattern-position idea. It may be tracking legacy, but it may also just be legacy from a time when RAM was precious and pattern-repetition was king. I dunno about you or others, but I usually go to the pat/pos screen once, and hold [N] for a while. Then I simple make my tune from pattern 000 until the last pattern. The chances of 100% repeat or so low these days.. even if you just add a triangle somewhere, the pattern is different already, even if you change a volume value, the pattern is different already. Why do I come up with this? If this is the pattern order: 000 001 001 002, and you want that to go to position 004..007, then what should you get? 000 001 001 002 003 004 004 005 or 000 001 001 002 003 004 005 006? |
|
| |
|
Developer
Posts: 746
Location: England | Actually, I tended to just brainstorm different ideas on different patterns before arranging them in the order list manually, then returning to the patterns to ensure that they flowed into each other. I never used IT's N-key once. My order lists were a largely random order, leaping from pattern 002 to pattern 198, to 197, to 003. It was great, in that it allowed me to experiment with different arrangements really quickly. I think one of the main strengths of trackers is that nothing's set in stone and that it's so easy to play around. If you set up a nearly sequential order/pattern arrangement and then use the patterns to affect the order, it'd have made my life more difficult.
Of course, this illustrates the other beauty of trackers - in that you're provided with a basic set of tools and its up to you to develop your own methods. CS_TBL, whose main genre is classical, perhaps benefits from the more structured, disciplined approach required by earlier commitment to an arrangement style.
Chris |
|
| |
|
Expert
Posts: 512
Location: Netherlands | The pattern/position chaos in some of those tunes always stunned me, how would anyone be able to understand all that after a few months of not touching it? It's like traditional line-number BASIC if you ask me.. :P And let's not even begin to mention copying a block of 8 patterns that belong together.. :P I tend to insert a few patterns now and then, but then it's always a group of patterns, like 4..6..8, but never just 'one'.. and typically also not 003 149 140 142 019 006 004 etc. That's why the pattern re-order functionality of IT was so brilliant. The main advantage for me is that I never need to go away from the pattern editor to navigate through my song, I just need to num+ and num- to go forward and backward, without worrying whether the pattern I'm going to will be at the respected location in time.
There is a point for sketching tho, but wouldn't it be better to have a special facility for that? Like a second set o' patterns in which you can sketch and mess around? (And of course use a multiple-pattern copy to copy the result of the sketch to the main patterns) |
|
| |
|
Veteran
Posts: 102
Location: Austria | chrisnash - 2007-12-01 3:10 PM
Thanks for the feedback, guys. CS_TBL: * hmm.. why did you restore the note-off upon === thing again? It was perfect the way it used to be.. I guess you never enter note-offs during playback..
Because it was requested. It seems there are some situations where you want it, and some where you don't. I'll think about making it toggleable.
i guess that came from my tests with note-offs in the 0.91 beta thread. but that was a little misunderstanding i guess:
chris: you already know the problem with note-offs still exists in reaper, but for some reasons the note-cuts do work. and as far as i understood both send the same midi message. now what i wanted to point out with the video i posted in that thread was, that there must be some reason why the note-cut messages are succesfully passed through to reaper and note-off messages aren't.
note offs do work:
- when reaper plays back the song
- during pattern preview in revisit
- when note cuts ^^^ are entered in the pattern editor
note offs don't work:
- when pattern preview playback is stopped with f8 (endlessly sustaining notes)
- when in instrument audition mode (which makes it impossible to play e.g. strings)
- when notes are entered in the pattern editor (also endlessly sustaining)
but now in 0.92 also the note cuts dont work any more! before posting this message i made a rollback to 0.91 to see if i'm getting crazy, but there the note cut's still do work. |
|
| |
|
| I'm also having this problem ... but not with all songs, only at least one. I can send the .cpr file, if you want.
fegi - 2007-12-01 12:36 PM
every time i reopen the project im currently working on i have === in the first row of the order list instead of 000.
this happens also, when i resave the project.
I also get some audio glitches using the reBus plugin - but not specific enough to see a pattern in it |
|
| |
|
| That was me, by the way, forgot to put the name 
Thanks for this excellent 0.92 Beta, it's totally awesome with the bus output thing!!
This is shaping up not only to be a great implementation of a tracker in a VST host, but also a great tool allowing things to be done that can't be done in any other way!! |
|
| |
|
Developer
Posts: 746
Location: England | Arnor,
I think I already have a .cpr from Fegi that does this, so I should be able to test the order list problem - thanks!
Can you describe the glitches in reBUS a bit more? Are they momentary? Repeating? Regularly spaced? What type of glitch (drop out, slight tick, etc.)? If you work out a way to repeat them, that'd be great.
There is one type of glitch I'm aware of - I believe it takes a little extra time to coordinate the reBUS/reViSiT communication and that there might be issues with how this is done. There might be a little bit of memory thrashing going on, which means the plug-in doesn't process the buffer as fast as the host would like (even though the CPU load is low). This seems to be confirmed when I increase the ASIO buffer size (and latency), and the glitches dissappear.
Let me know if increasing the buffer size helps (and what the original/new values were/are) and what soundcard and driver you're using. I'm actually using ASIO4ALL, with a buffer size of 768KB (originally 512KB).
Cheers,
Chris |
|
| |
|
Member
Posts: 10
| Yeah, I found out what my audioglitch problem was.. it was just in one song, and when I examined better I saw that I had the reBus thing on an audio track as an insert point, instead of on an FX track.. When it's on an FX track, everything is smoothe... I can't get the instrument->bus thing to work though, might just be misunderstanding... also the difference between setting buses in the preferences tab VS. using the channel mixer/view is a bit confusing.. seems like the preferences tab is not completely active or something.. :/ ? |
|
| |
|
Developer
Posts: 746
Location: England | Hi Arnor,
reBUS should really work no matter where you stick it in the host. Even if the reBUS buffer is processed BEFORE reViSiT, it should still work - so I'd be grateful if you could mess around with reBUS in the Inserts and see what happens. Does it ever work correctly as an Insert?
Let me know how you're going about assign busses to instruments and perhaps I can point you in the right direction. Here's a quick recap of the routing options:
In the Order List / Channel Configuration (F11):
You can set the default bus used by a tracker channel. This is the bus the channel uses by default, and the "factory" setting is just Bus 01 (e.g. the Main bus) for every channel. Playback a song and each note in a channel will check what the default bus is and output to it. However, the default bus can be changed using the S0x pattern effect, during a song. Put in S01 in the pattern and the default bus will change to "Bus 02" (because the effect is zero-based) when that effect is triggered. Following the effect, all notes will output to this new bus instead. If you stop the song, then restart playback, the setting specified in F11 is used - just like Channel Volume (F11) and the Mxx command. In Preferences (F12):
Here, you set up how to configure busses and have a number of extra routing options. The matrix on the right allows you to send a specific channel, instrument or sample (see the three tabs) to a specific bus. These are done in addition to the default routing mentioned above (unless the default routing is "(none)", in which case only the matrix is used). You cannot use pattern effects to change the matrix settings, but you can change the matrix settings in the F12 screen (e.g. with mouse or keyboard) during playback, and the routings will change instantly, during playback. This is handy for just messing around with different mixes and submixes. --- Possibly what confuses the two a little is that the F11 default bus setting is also shown (and can be edited) in the F12 matrix: the F12 matrix settings discussed above are shown as filled-in circles, set with the left mouse button, cleared with the right. The F11 default bus setting is shown as a hollow circle, and toggled with the middle mouse button. It is possible to have the hollow circle (default bus) and filled-in circle (matrix assignment) together - it looks like a bigger filled-in circle! In this instance, the channel is being sent to that output twice (both as the default and as an additional matrix routing) and will have the effect of doubling the volume. Even this can be useful if you just want to bring a submix to the foreground while you concentrate on it. 'Hope this helps! Chris |
|
| |
|
Expert
Posts: 512
Location: Netherlands | any 0.93 with multiple-pattern-copy and some other fixes on its way for xmas? :P |
|
| |
|
Veteran
Posts: 102
Location: Austria | i had a long tracking session last weekend...and i'm not sure if it was revisit's fault or reapers fault, but i got system crashes like every 2 hours. one thing i'm sure is, that it always happend when hitting f6 in revisit. did anyone else experience a similar behaviour in 0.92b?
ps: hurray to automatic backups |
|
| |
|
Developer
Posts: 746
Location: England | Ok, nailed the === order list bug. Only occured when loading documents saved with save-with-host. The loading mechanism wasn't updating the length of the order list.
Chris |
|
| |
|
Developer
Posts: 746
Location: England | Ok, I've changed the Note Off/Cut audition behaviour to something that should suit all tastes. A note off is auditioned upon entry if and only if: a) reViSiT is not playing a pattern/song, or b) reViSiT is playing a song and Pattern Follow is enabled.
I've also found a way around REAPER's odd MIDI behaviour. It looks like MIDI messages can only be sent to the host during audio processing (possibly, therefore, only from the audio thread). The MIDI resets, note offs, etc. that weren't being triggered were being sent using the UI. As far as I know, REAPER is the only host that behaves like this, but I've changed reViSiT so that UI-triggered MIDI events add to a MIDI queue, so that the audio thread can trigger them instead. As such, MIDI appears to work fine in REAPER now, and (as far as I can tell) hasn't broken in any other hosts. Ironically, what led me to the discovery was Fegi's report that Note Cuts had stopped working in v0.92. The only reason they worked before v0.92 was because of a bug in the code, that caused the MIDI message to be (wrongly) sent in the audio thread instead of the UI thread!
To address CS's sustained notes, I've added the "All Sound Off" message to the MIDI reset function (F8). Previously reViSiT sent "All Notes Off" and "All Controllers Off". It would appear that All Notes Off doesn't terminate sustained/held notes, and also that All Controllers Off releases the hold pedal, but not the held notes. CS, let me know if it works. If it doesn't, I'll take it out, because otherwise it's just slowing down the reset sequence.
I hope to have the forthcoming v0.92.1 out soon, featuring these changes/fixes and some substantial performance improvements. There should also be a built-in crash-report system, to help me debug any problems you might have. If you can think of any bugs that haven't been reported or haven't been mentioned as fixed, now's the time to mention them!
All the best,
Chris |
|
| |
|
Expert
Posts: 512
Location: Netherlands | mmmmmmwell, there's always things I can mention.. but they're more like functionality/interface fixes than that they are really bugs. And when it comes to interface fixes then they're highly personal of course, so I just mention what I'm bumping onto each time:
* Sometimes I try to move the reViSiT window (get it out of the way so that other VSTi's aren't blocked visually), but incidentally I resize it because I grabbed the wrong pixel. Possible solutions:
1) have a button/key (but preferably a button, to free up keys) to lock the size of the pattern editor
2) don't allow resizing when the reViSiT window is partly off-screen (which is usually the case when one's moving it away from other VSTi's, or e.g. the mixer of cubase)
3) don't make the window resizable using the traditional convention "edge-of-the-window", but define the window's size within reViSiT by filling in 2 editboxes in preferences: "amount of visual steps vertically" and "amount of visual tracks horizontally".
My preferred order is: 3-1-2
* Do we need the instrument name clickable, on top of the reViSiT window? Does anyone ever use that? (esp. considering that those other numberfields on top of the screen aren't clickable!). Point is, during window move, you may grab it somewhere around that instrument name, and then you are -guess what- selecting an instrument rather than grabbing the window.. :P
* That debug report system sounds like a good idea, but perhaps it could be enhanced with a generic monitor on specific critical events or situations? Stuff I still have -tho honestly I'm using .91 but I don't think the issues I have were addressed in the most recent version- :
- slow update when giving track names or window resize
- sometimes the odd note hangs
*if* such a debug system (a popup showing some relevant variables?) could show me stuff during trackname typing or window resize, it'd perhaps be easier for me to report issues and thus for you to fix these issues. btw, just from the head, my reViSiT system is a dualcore, does that matter here? Once my system exposed a dual-core related bug in an MSX emulator, so I guess sometimes there may be dualcore issues. Could it be a generic event monitor?
* I'm now talking for myself, but I've never used those 2 characters in an instrument name (used to be numbers, but can now be everything). Sometimes I c/p an instrument to the next instrument slot (being a variation for example), and then it copies those 2 chars along. If these were a number, then you end up with 2 instruments with the same number (unless you retype that number, which one tends to forget). I've been gazing at the pattern editor more than one time, wondering why the instrument < > keys were acting so odd: the instrument changed, the number didn't.. :P
* track-naming and track-coloring could be faster/more intelligent. How about having a pre-defined list of instruments somewhere, and then instead of typing 'Violins' you simply hit a pre-defined key (or with +ctrl) and the word 'Violins' comes from that list. For a moment, just think about how much time it costs to rename 40 tracks. All the same for colors. The color-requester is a windows gadget, nothing in common with tracking-interface-conventions. How about using hsv colors, with the h under the keys 0..9 and the b on 25..50%? Then it's just a matter of moving the cursor and pressing keys 0..9, that's rocket-speed!
Bedtime! Enjoy these features ^_^
Edited by CS_TBL 2008-02-12 1:28 AM
|
|
| |
|
Veteran
Posts: 102
Location: Austria | chrisnash - 2008-02-11 9:35 PM
I've also found a way around REAPER's odd MIDI behaviour. It looks like MIDI messages can only be sent to the host during audio processing (possibly, therefore, only from the audio thread). The MIDI resets, note offs, etc. that weren't being triggered were being sent using the UI. As far as I know, REAPER is the only host that behaves like this, but I've changed reViSiT so that UI-triggered MIDI events add to a MIDI queue, so that the audio thread can trigger them instead. As such, MIDI appears to work fine in REAPER now, and (as far as I can tell) hasn't broken in any other hosts. Ironically, what led me to the discovery was Fegi's report that Note Cuts had stopped working in v0.92. The only reason they worked before v0.92 was because of a bug in the code, that caused the MIDI message to be (wrongly) sent in the audio thread instead of the UI thread!
CHRIS! that is amazing news!!!! man i'm totally excited and looking forward to trying it out oh and...btw i didn't have any more crashes in my last session, so i'm pretty sure it was reapers fault that other night. |
|
| |
|
| Hi guys,
I just wanted to say THANKS to all of you developers, I have been creating beats with IT for years now and still have my Pentium 500 cause it has DOS-mode for running IT. I tried Renoise, but the later versions didn't support the IT keyboardmapping.XML anymore. Schismtracker offered me a great alternative and then I stumbeled upon revisit. You did a great job at the keymapping, great that it is identical and as comes as a VSTplug!
That's all, I will keep using it and supporting.
Greetings from the Netherlands,
Cyclus |
|
| |
reViSiT v0.92 Beta released!
