PlanetZ forums - scopeusers.com

Everything about midi: MIDI Manufacturer's Association, MMA.
Another view on Midi specs
http://www.borg.com/~jglatt/tech/midispec.htm
Main page: http://www.borg.com/~jglatt/

MMA's 'What is MIDI' page is a basic intro guide, but had something very new to me - at the bottom of the page. I then removed the cheapo soundcards which I got for their joystick port Midi-connections.

[edit: added some links] http://www.hinton.demon.co.uk/midi/promidi.html very techie, but complete.
http://www2.netdoor.com/~johnfera/MIDIsumm/Midi.html
http://www.mtsu.edu/~dsmitche/rim419/mi ... tents.html

<font size=-1>[ This Message was edited by: at0m|c on 2004-12-14 20:49 ]</font>

SoundOnSound about midi remote:

http://www.sospubs.co.uk/sos/oct01/arti ... an1001.asp

Cheers atOmic, great links!

You're welcome There's a lot that I could type out myself. But if it's ok w you guys, I'll reply here to any midi questions that may arise for Pulsarians, upon reading the above links or just when you run into them working with SFP. Gimme a shout!

Hi,

I have a remark about general SFP CC# remote. I noticed the Studiomix devices use all CC#; including CC# 0, 1, 32,... which are not useable for me: 0&32 are bank/prog change commands, CC#1 is reset on 'Stop' in loads of sequencers. I think midi 'stop' also covers 'reset device', which means modulation (CC#1) will be reset.

I'm no Studiomix user, I have a Pc1600. When I created the Pc1600x midi remote control presets for CW devices, I noticed that some CC# are not useable for fader control.

For example:
CC# 0,32: bank select & program change,
CC# 1: modulation, is reset (read set to 0) on midi Stop
CC# 6: MSB (it's LSB will be in CC# 32-63 but 33-63 is perfectly useable for fader remote)
CC# 98-99: Non-Registered Parameter Number (NRPN) LSB-MSB
CC# 100-101: Registered Parameter Number (NRPN) LSB-MSB
CC# 121-127: Reserved for Channel Mode messages.

I don't know exactly from which of these CC# are filtered/abused where. Ie. CC#1 is reset by Cubase on Stop and is on opening of a project or sequencer.
CC#0 is already assigned to bank select in the DSP device.

It may be very boring info, but it's quite important to know. It's not very funny to make mistakes, when you had it all written down on paper and finally made it all look very logical. If you then discover you have to reprogram everything...

I want every possible knob controlled, so I need to make these presets. I hear of people assigning CC# per CC# as they go thru the song, but that's ehm impossible time eating work if you want everything to work remotely. I mean, I don't know which knob I'm going to tweak and once I'm doing music I don't want to think about assignments no more. I want it there all ready.

Are you in for some midi fun?

Related:
http://www.midi.org/about-midi/abtmidi.htm
http://www.planetz.com/forums/viewtopic ... 41&forum=1
http://www.planetz.com/forums/viewtopic ... 6&forum=13
http://www.planetz.com/forums/viewtopic ... forum=16&6
http://www.defectiverecords.com/pc1600/pc1600.html

Relative MIDI values and Creamware by ...

algorhythm,

Maybe it's not really what you mean, it should be technically doable already, if I understand how the continuous controllers [RCD] you talk about work.


Load a device and it's CC# preset. Then load a classic preset. When you load a new preset, some knobs will jump to a new position. These knobs, assigned to CC# by the initial CC# preset load, send their new CC# values to the output. And they will do so every time you move them with your mouse or sequencer automated.

This CC# stream, you can use to update your RCD. I use it on the Pc1600x, it's called 'update' function. In 'update' Pc1600x will read incoming data, and when they correspond to currently available sliders and buttons, moving sliders and buttons will start from their last received or 'updated' value.
'Update' has it's pro's and it's con's. You need to keep updating the RCD, unless it has a large memory and remembers every CC# update from every device. Or some other initialisation of the RCD.


I choose to use 'update' in all my presets. There's 2 more modes on the Pc1600x:
'Merge' mode mixers both incoming and locally generated streams, while 'replace' will filter the incoming CC# when it's locally generated.

Can this be used for continuous RCDs? I mean, what they have extra to ie. a Pc1600x is continuous motion knobs. A slider has physical limitations But actually it generates the same data, it's just how movements and input are interpreted by the RCD, using endless encoders (alpha dials) or fixed-range potentiometers. [edit: see algo's reply below]

It works for me on a reasonable amount of devices, but some have problems with CC# presets or assignments. Or maybe it's a hidden option on some


How do Continuous RCDs update? Do some programs allow the RCD to send anything, and does the controlled program translate incoming midi or another signal? This would make it hard to send snapshots or to tweak real fast. Is continuous midi a new kind of midi code? [edit: see algo's explanation below] I've not heard about it then...
How about RCDs using USB and screen capturing?


Once in a while my machine's faders wear [read: unpredictable CC# output;]. Then we replace the fader. It's my 3rd, in 5-7 years. Bugfree.

algorhythm, do you have such a (continuous) RCD? Or anyone else? What do you think about it?

at0mic.

<font size=-1>[ This Message was edited by: at0mic on 2002-08-14 03:13 ]</font>

<font size=-1>[ This Message was edited by: at0mic on 2002-08-14 11:19 ]</font>

I thought of sharing some Midi Clock freakness.

Neutron, AFAIK, all dsp synths/seq behave like this, so don't worry.

A while ago I had problems with a device with built-in sequencer. Sometimes, it had problems catchingup on / refreshing BPM. It was this start/stop signal that was filtered in one of the test projects, and I neglected the filtering. I thought 'all it needs is clock'.

Hooked up Sonic Attack to Midi from mc505. Sonic Attack's BPM set to external, to receive 505's sync. It shows ie. 60 on the SA. I press play on 505, the SA BPM starts following the 505, ie. at 132bpm. If I then stop the 505 , SA's bpm holds some 'last recognised value', mostly very close to the 132. Sometimes it's a little off, but that's no problem. The sequencer's stopped anyway, nothing's supposed to be playing.

Oki, now i start 505, with SA to Ext, it follows 505's bpm. I switch SA to Int, and thén press stop on 505. Set SA to ext again, and BPM keeps following 505's sync signal, SA has missed the 'stop' signal, it keeps 'running'. Or filter Start/stop before SA, let sync pass. It won't sync. So there's something reacting to Start/stop.

I bet this allows the sequencer, even not in retrigger mode, for running synchroneous with the master. To return to it's position 1-from-16 when ie. Fruity plays 1-from-16. This can be quite usefull if you want to predict/program how the sequencer sweeps will go, like 'modulate knobs a,b,c up on beat2 & down on beat6 with this exact value'. It unloads a lot of midi remote -alhthough the Pc1600x fits nicely on a 16-step sequencer

Some sync nicely or have built-in BPM settings, but might be out of phase with another modulation/rhythm. Out of phase is not good or bad, it's different. Some devices do not sync, ie classic phasers. Guitar padel phasers have worked long time with rough LFO frequency settings. And still do.

Different devices are cool, they broaden creativity and our card's possibilities.

Enjoy,

at0mic.

On 2002-08-14 02:53, at0mic wrote:
Relative MIDI values and Creamware by ...
algorhythm, Maybe it's not really what you mean, it should be technically doable already, if I understand how the continuous controllers [RCD] you talk about work.

hi atomic. these are very close. what you speak of is called "midi feedback," and yes the doepfer pocket - it should work. This is still not relative though (the cc#'s used are still absolute), and my request still stands.

AFAIK, relative MIDI commands "bend" the MIDI protocol and were not part of the original spec.

to answer your questions: how do "rcd" update? they don't! they don't take MIDI feedback, you only have to have a MIDI out from the RCD device to the host. The necessary bit is that the Host must support relative MIDI. Ableton Live supports this, and it is precisely why I bought a RCD MIDI device. How do I like it? It rocks! You look at the software and not the hardware, there is no "real position" on the hardware, it is an endless encoder. You use your ears and eyes on the screen. The knobs are a bit clicky/not smooth (stepped not continuous values) and that takes getting used to, but works fine for me.

_________________
.: algorhythm :. http://www.algorhythmz.com
It is better to fail in originality, than to succeed in imitation.- Herman Melville

<font size=-1>[ This Message was edited by: algorhythm on 2002-08-14 07:39 ]</font>

Is Relative info added to the MIDI spec? YES.

http://www.doepfer.de/home_e.htm

1. Pocket Dial transmits Increment / Decrement Data

In this case Pocket Dial does not "know" the absolute value of the parameter but transmits only the information data increment (abbreviation: inc) or data decrement (abbreviation: dec). Unfortunately there is no MIDI message available "increase data of MIDI Controller XX" or "increase data of MIDI Controller XX". There is only a general Data increment (Controller #96 decimal, resp. #60 hexadecimal) and Data decrement message (Controller #97 decimal, resp. #61 hexadecimal) available. The third byte of these messages is - as far as we know - not used so far. In the MIDI spec we found no statement concerning this byte. Remember: each MIDI control change message consists of 3 bytes. We want to solve this problem by "hiding" the controller number, to which the inc/dec is related to, in the third byte of these messages. This modified inc/dec messages would enable to increase or decrease the value of a specific MIDI controller. We hope that other companies will agree to this proposal and adjust their software/hardware to this amendment of the MIDI Data increment/decrement message (controller #96/97).

The "new" MIDI messages are:

Controller Increment: BnH 60H xxH

Controller Decrement: BnH 61H xxH

with n = MIDI channel (0...F) and xx = MIDI Controller No (00...77H, 78H...7FH is reserved for Channel Mode Messages). H means hexadezimal values.

BTW At0mic the sequencer in Sonic Attack is a bad example because it is not a real creamware sequencer. It is much simpler.

The midi clock will behave the same but the sequencer will not react to it in the same way as a normal creamware sequencer. neutron sequencer behaves just like a synced LFO. it will retrigger when a new note is hit (and it is monophonic).

It will not reset itself with a midi start/stop command. but if the midi clock is stopped it will appear to stop as the clock will telling it to run at zero BPM.

Thanks Neutron

But then how does one explain the following:

The 505 does not stop transmitting clock, it continues to send midi clock after stop. It sends clock whenever Sync Out is on.

If I filter the Stop signal, Sonic Attack's BPM continues to follow (you know, small shifts up/dn around received clock). If the stop command is not filtered, it holds it's BPM to last identified.

I then loaded planetz's Zorba, a multi-effect which also sync's to external clock. Zorba has an LFO, but no sequencer. It also stops at it's last identified incoming BPM setting, together with the stop command from the 505.

If I make the correct conclusion, the BPM and start/stop is interpreted by something between midi input and BPM display. But what? If possible, then how can it be used to reset to ie. beginning of a pattern/LFO phase?

In that case the Midi clock module is responding to start stop. it has those outputs as well but i did not have a place to hook them to the sequencer yet.

huffcw wrote in the Device/module Wishlist forum:
I wonder if a third-party device might be able to make this [Soft Takeover For Controllers] work. (...) Is it possible?

Hi,

Various devices have the function since long. Since I (and many other pulsarians;) use the pc1600x, I'll take it as an example. The Pc1600x has such an "update" function.

* Setup.
Connect Pc1600x to dsp mixer input, and mixer's output to Pc1600x. Establish midi remote, assign CC# to mixer controls etc.

* No glitches.
P1600x faders can receive incoming CC#. Faders corresponding to that CC# will be virtually set to incoming values. They send last received value as a starting point when they're moved. No more glitches.

* Backdraw.
This is nice for smooth controlling, but on the backside lies the changing range of these faders. Let's suppose fader is at position 100. It receives position 30, thus faders virtual position is at 30. Now the fader can only go up 127-100=27 values. Max sent value will thus be 57, the fader won't go higher untill u give it a full up/down cycle (below position 100-30=70 it will send value 0 (since it's been updated previously). Whenever raised again in that range from 'sending 0', it will send raising CC# starting from 0. As such, to return to a full scale 0-127 range, the fader has to be cycled a full range.

I usually try to calibrate volumes elsewhere, so the Pc1600x and dsp mixer's controls give a rough mix in an initial setting (volume 100, pan 64 etc). This avoid faders being far out.

There's many other controllers around, I suppose most programmable controllers have the update function.

Enjoy,

at0mic.

Thanks for the reply - but how about setting this up in a virtual device for SFP that would convert any midi controller input to work this way?

The big thing here is being able to use any controller the user wants in SFP effectively. If there is a SFP device that could be placed between the midi input and the synth/mixer that would basically do the same thing as soft takeover or what you have described wtih the controller you use, that would be great.