Search | Statistics | User Listing Forums


Forums supporting
reViSiT (http://revisit.info)
and MIVI (http://mivi.nashnet.co.uk)
nashNET Forums ->  reViSiT - Tracking Software for VST hosts -> Testing & Development -> View Thread

You are logged in as a guest. ( logon | register )

Midi CC:s in reViSiT
Jump to page : 1
Now viewing page 1 [25 messages per page]
View previous thread :: View next thread
   reViSiT - Tracking Software for VST hosts -> Testing & DevelopmentMessage format
 
elfani
Posted 2004-11-29 4:23 PM (#13459)
Subject: Midi CC:s in reViSiT


Member

Posts: 15

Location: Sweden
We have discussed how midi should be sent from reViSiT to other VST plug-ins and to other midi destinations. What I think we haven't discussed is how midi works inside of reViSiT. For example: If I want to send a couple of notes together with a couple of cc commands from the note sheet in reViSiT to another VST plug-in, would that be possible? Let's say that I want to send the value 58 to cc #23 together with a note which I have programmed in the note sheet, would that work?
An idea is to have assignable tracker effects that map to midi cc:s, so that if I want to send midi cc #23, then I assign that cc to effect Zxx (or some effect that is available) using some tool inside reViSIT and set a value in ordinary tracker style, like Z 58 in the note sheet.

Does this make sense?
Would it work, or would it work in some other way?
Is it a stupid idea, or what? Do come with suggestions .

//Tomas

Bookmark and Share Top of the page Bottom of the page
chrisnash
Posted 2004-11-30 12:52 AM (#13460 - in reply to #13459)
Subject: Midi CC:s in reViSiT



Developer

Posts: 746
50010010025
Location: England

Hi Tomas,

I have indeed been pondering about this, and how to provide greater expressivitiy with MIDI communication, including CC's. It seems unlikely that there will be enough spare letters in the alphabet to make using Zxx (or similar) possible - especially since I can already think of non-MIDI features that can fill the available spaces!

The thought, however, does occur that the numbers are not used yet. So, here's what I'm thinking. Each instrument will acquire a list of ten user-specifiable MIDI CC's, to be assigned to the numbers 0-9. To address them on the pattern editor, one will simply press a number on the keyboard, in the effect command column (where the letter normally goes). So as not to overload the pattern editor's interface with numbers (e.g. avoiding the effect [1][9][8] - command '1', parameter '98h'),  I will make it so that they appear half width, next to an appropriate letter (e.g. [M1][9][8] - the "M1" will fit in the space of a normal character). Furthermore, numbers open up a further raft of possible commands, when used in combination with the alt, shift or control key.

Unmodified might be Mx (MIDI CC's), Shift could be Sx (Sysex?!), Control could be Cx (MIDI Control?!) and Alt could be Ax (Another feature...?). It just remains for me to think of actual commands to use them for! Alternatively, the shift could be used to address M10-M19, control M20-M29 and alt M30-M39, thus allowing up to 40 CC's to be used for each instrument. Though, it occurs that simply defining one global set of CC's (rather than instrument-specific sets) might be more productive - allowing people to swap instruments and still get the same MIDI effect.

However, all this musing is speculative at best - such advanced MIDI functionality will probably not make the agenda for v1.0. For v1.0, I hope to get MIDI to a state where it is as flexible and as compatible with audio, as much as possible: pitch, volume, channel panning (not note panning - MIDI doesn't support that), slides, etc. A midi Jxy command is going to be very interesting, but I think it's possible!

All the best,
Chris

PS: Did a little work on reViSiT this evening. The combination of VST Midi (direct to Host) and Win32 (direct to MIDI drivers) systems appears to be holding up. I haven't tested it extensively yet, but the two systems do seem to be in sync by default (both near-zero latency). Current MIDI support is for note on, note off (===), initial volume and initial pitch - which doesn't put me to far off IT's rather menial MIDI feature set already! A v0.86 release might be a possibility before the end of the week, but no promises.

 


Bookmark and Share Top of the page Bottom of the page
elfani
Posted 2004-11-30 9:15 AM (#13461 - in reply to #13460)
Subject: Midi CC:s in reViSiT


Member

Posts: 15

Location: Sweden



Hi Tomas,I have indeed been pondering about this, and how to provide greater expressivitiy with MIDI communication, including CC's. It seems unlikely that there will be enough spare letters in the alphabet to make using Zxx (or similar) possible - especially since I can already think of non-MIDI features that can fill the available spaces!The thought, however, does occur that the numbers are not used yet. So, here's what I'm thinking. Each instrument will acquire a list of ten user-specifiable MIDI CC's, to be assigned to the numbers 0-9. To address them on the pattern editor, one will simply press a number on the keyboard, in the effect command column (where the letter normally goes). So as not to overload the pattern editor's interface with numbers (e.g. avoiding the effect [1][9][8] - command '1', paramet





It sounds like you've thought it through . It will probably be great in the end. The reason I'm asking is because I've been wanting to do one very special thing using reViSiT: To send midi notes to a VST plug-in instance of Native Instruments Battery from reViSiT and at the same time control the sample offset in Battery using midi cc's from reViSiT. It would be just like the ordinary tracker style, only that the sampler would be kept in an external plug-in. I've been longing for a way to control cc's using a parametric, step-time interface - like a tracker - and to control sample offset without using those annoying graphic automation envelopes in Cubase, Logic and other VST hosts. reViSiT could really make a difference here !

Thanks a lot for all of your hard work!




PS: Did a little work on reViSiT this evening. The combination of VST Midi (direct to Host) and Win32 (direct to MIDI drivers) systems appears to be holding up. I haven't tested it extensively yet, but the two systems do seem to be in sync by default (both near-zero latency). Current MIDI support is for note on, note off (===), initial volume and initial pitch - which doesn't put me to far off IT's rather menial MIDI feature set already! A v0.86 release might be a possibility before the end of the week, but no promises.





Weee! Sounds awesome . Which direct-to-MIDI drivers are you using then? Are you sending to the hardware midi interface on the soundcard or using some kind of loopback? The latency sounds great . I'm really looking forward to testing it.

Bookmark and Share Top of the page Bottom of the page
chrisnash
Posted 2004-11-30 11:04 AM (#13462 - in reply to #13461)
Subject: Midi CC:s in reViSiT



Developer

Posts: 746
50010010025
Location: England

It sounds like you've thought it through . It will probably be great in the end. The reason I'm asking is because I've been wanting to do one very special thing using reViSiT: To send midi notes to a VST plug-in instance of Native Instruments Battery from reViSiT and at the same time control the sample offset in Battery using midi cc's from reViSiT. It would be just like the ordinary tracker style, only that the sampler would be kept in an external plug-in. I've been longing for a way to control cc's using a parametric, step-time interface - like a tracker - and to control sample offset without using those annoying graphic automation envelopes in Cubase, Logic and other VST hosts. reViSiT could really make a difference here !

Well, since the Oxx (Sample Offset) command won't have any use for standard MIDI, I don't see why it can't be used to send the MIDI CC's to control Battery's sample offset. I don't suppose there is any standardisation among MIDI instruments about CC/Sample Offset? Is there a standard CC #? I know some have official designations (reverb, etc.), but is there any implicit specification?


Weee! Sounds awesome . Which direct-to-MIDI drivers are you using then? Are you sending to the hardware midi interface on the soundcard or using some kind of loopback? The latency sounds great . I'm really looking forward to testing it.

The direct-to-MIDI approach doesn't involve any "special drivers" - just calls to the Win32 API / Kernel (and perhaps DirectMusic, implicitly). So, any MIDI driver (external or loopback), that is installed in Windows, will be available to reViSiT.

Regards,
Chris


Bookmark and Share Top of the page Bottom of the page
elfani
Posted 2004-11-30 11:19 AM (#13463 - in reply to #13462)
Subject: Midi CC:s in reViSiT


Member

Posts: 15

Location: Sweden
Reply to : chrisnash



Well, since the Oxx (Sample Offset) command won't have any use for standard MIDI, I don't see why it can't be used to send the MIDI CC's to control Battery's sample offset. I don't suppose there is any standardisation among MIDI instruments about CC/Sample Offset? Is there a standard CC #? I know some have official designations (reverb, etc.), but is there any implicit specification?





Even if there is a standardisation for sample offset I really don't think that people would follow it. In my experience people only tend to follow standards for basic things such as sustain pedal, mod wheel and bend wheel and stuff like that.
Besides, Battery listens to any CC and maps it to internal parameters such as sample offset, so it doesn't matter which CC you use. I have never learnt which CC is designated for what since it has always been possible for me to map between arbitrary CC's and parameters as I please .
So, as long as there is an easy, flexible way of sending arbitrary CC's + midi notes from reViSiT, then I'm completely satisfied .

//Tomas


Bookmark and Share Top of the page Bottom of the page
Jump to page : 1
Now viewing page 1 [25 messages per page]
Jump to forum :
Search this forum
Printer friendly version
E-mail a link to this thread

(Delete all cookies set by this site)