<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
--></style>
</head>
<body class='hmmessage'>
fons wrote:<br>> to send a stream of<br>> parameter updates, and then it all depends on the receiver<br>> if this results in a 'staircase' or a smooth trajectory. <br><br>Agreed, and the MMA advises on a few of them such as the pan<br>mentioned in the last submit and the fact that the MMA only <br>advises on a few of them just highlights the limitation.<br><br>> The advantage of a defined rate (audio or sub-audio) 'CV'<br>> style data type is that at least that interpretation is<br>> defined - it is bandlimited by its sample rate and that<br>> more or less imposes the only valid way to interpret it.<br><br>Perhaps the only issue I have is the naming. What is being<br>proposed - another message format over another port type<br>in jack?<br><br>The existing tuxfamily definition uses a jack audio port to <br>carry samples that provide the control 'voltage', in this case<br>as floats. This is a pretty cool method and a few people have<br>expressed interest in having it more generalised. A separate<br>port type could still be defined for quantised messages but then<br>somebody would have to write jcv2cvd to convert that back into<br>samplerate floats for the synths to work with.<br><br>What it comes down to is that the fully programable synths<br>(arp2600, moog modular, ms20, matrix, synthi) allowed <br>anything to connect to anything, that means the patching<br>has to support native formats, currently floats at the native<br>sampling rate. If you introduce another 'CV' based on sub-<br>sample 16 bit values then you introduce another special<br>case that needs to be catered for.<br><br>As such don't see how they could be reasonably used in <br>conjunction. Take the case of the ARP2600: all of it osc<br>can modulate all the other osc. At low frequency these could<br>be passed as your s/16 messages. What about at audible <br>frequency when you want to get FM type effects - is this CV<br>supposed to be changed depending on whether the signal<br>is LF or AF? If so, where is the cutover done? This kind of<br>modulation has to be carried in the native format.<br><br>Since audible frequencies are the only ones that will work<br>for FM and other effects then it is pretty much a done deal.<br>The data needs to be passed at the native rate between apps.<br><br>If some synths want to have quantised parameters that is fine,<br>but that really isn't CV and using such a name obfuscates<br>what is going on.<br><br>> Another limitation of MIDI is its handling of context, <br>> the only way to do this is by using the channel number.<br>> There is no way to refer to anything higher level, to<br>> say e.g. this is a control message for note #12345 that<br>> started some time ago. <br><br>This is also very true. It does raise the question of how much<br>data you want to carry in these f/16 messages - it now includes<br>timing information, note information, data information, some<br>arbitrary concept of channel, it may need to carry a MIDI<br>mapping of some type, probably also sequence numbers<br>for ordering, information on the source of the message, etc.<br>The amount of data being passed at a rate of f/16 will be very <br>close to f for continuous changes as these messages are going<br>to be much larger than a sample of type 'float'. They are also<br>going to be a lot more laborious to process. I still feel that the<br>CV should remain floats at native sample rate and apps that<br>want to quantise should just pull out every n'th sample.<br><br>> As far a I can see, any application dealing with control<br>> data should offer MIDI only as one possible I/O format,<br>> but certainly not use it internally, or be based on it.<br><br>Your initial interpretation of MIDI was just a way to get some<br>data from A to B. That is true, but wasn't a large part of the the <br>actual goal to find a way to digitise CV from A to B? Perhaps<br>it is time to get rid of the messages and get back to the original<br>issue of moving analogous signals around and recognise that<br>in the current digital world 'analogous' is floats/samplerate.<br><br>It is then up to the app to decide whether it wants to quantise <br>those values.<br><br>That doesn't actually respond to the point you are making here<br>though - MIDI should certainly not be used internally to an <br>application. Again, very correct. This does skirt around the<br>issue that applications need a midi interface, and that when<br>modulating audio data they need some form of audio interface<br>between the components. Proposing what appears to be an<br>enhancement to MIDI for the modulating interface just imposes<br>an extra level of complexity where an extra port is needed for<br>the 'new CV' data, the audio data needs to be mixed with the <br>'new CV' definition since it is not really reasonable to expect the <br>'new CV' definition be used to carry audio samples for internal<br>modulation paths. Unless the new CV really is an audio stream.<br><br>Nick.<br> <br /><hr />Hotmail: Trusted email with powerful SPAM protection. <a href='https://signup.live.com/signup.aspx?id=60969' target='_new'>Sign up now.</a></body>
</html>