thanks - now i understand the MSB linked to value - but I still don’t understand the LSB - what does 3 represent? why not 1 or 2 or 0?
it’s 3 of what?
it doesn’t matter cos it’s too fine to make any difference!
using the metres vs centimetres analogy: it’s like your CC will travel a metre every value change,
that’s the MSBtiny
now we don’t have a way of travelling all those centimetres inbetween, so we just leave it fixed to an argument.
(In the pic above: If I’m making a Big Red Jump with every small movement of the dial/lever, it doesn’t matter which of the Tiny Blue steps I’m on inbetween!)
So we set the MSB to the CC value and leave the LSB constant.
Remember my PitchBend Monitor earlier?
Here’s the Raw Display view:
see how the middle of the 3 codes is always 0?
That’s the LSB always at 0 cos that PitchBender is low res.
So the Transform setup I posted will recreate that.
Try it…
…preferably with your Monitor working! (check your Incoming Filters )
1 Like
ah ok, now i understand the graph
but - if you start at 3 instead of 0, aren’t you aways going to be 3 of microsteps off?
yeah, but if you can hear the difference you’ve got a better ear than me!
and off what?
1 Like
ha, good point
as for off what - i guess if your externally controlling the pitch for example and you have it set to a number other than 0, you’ll always be slightly off
is there any reason that the default is 3 instead of 0?
Fun aural experiment:
set a constant tone on Sirin
Set Sirin to a pretty narrow PB range
set up a knob CC Transform( Val → LSB)
listen for how big a jump you need to make to be able to hear it!
In my (limited) experience really fine changes come into play with stuff like FM atonalities and Comb filters.
1 Like
My guess is the same reason LFO defaults to CC#3
so they’re defaulting the “Which?” to 3 and the “How much?” to 0.
I chose Arg2 for LSB just so I didn’t need to change the Arg!
PS. Are we Solved?
1 Like
makes sense
and yes, solved - thank you very much for your time and patience!
we’ll see if it works like it’s supposed to…
i think i have my set of pipes programmed, except I also need to filter out all of the cc’s that match sirin’s high res CC’s…
ooh i need to make a feature request that we can name each row of of commands because if something doesn’t work, finding it will be annoying when there are 40 odd rows…
something doesn’t work, finding it will be annoying when there are 40 odd rows
Message me with a list
CC# in → CC#
I’d be suprised if you can’t make it more compact.
Personally I couldn’t put a complex patch together without lots of Monitoring In & Outs of different pipes. So getting Monitor working is top priority, IMO!
1 Like
I’ll leave you to decide which post was the Solution!
1 Like
it’s more complicated than that, i’ll send you the midihub file instead
i think half of them are the solution!
not sure what the problem is - itried it with the cobalt plugged directly into the computer, and then again with cobalt plugged in to the midhub, which is connected to the computer
So if
Cobalt is plugged into DIN A,
Midihub is showing as Connected in the Editor,
MIDI A-IN is selected,
do you get nothing in Midi Monitor?
1 Like
Very stupid question - how do I select MIDI A-IN?
snap below is selecting MIDI-A OUT:
the pipe gets highllighted,
the Monitor pane is cleared and starts to fill up with the events going through the selected pipe.
this is from Step-by-Step.03: Monitoring incoming messages which is useful for learning about using montoring to help you focus on the messages you want to see whe setting up and testing a patch
1 Like
you mean just click on the TO A? nothing happens in the monitor
yes to both - though not 100% sure clock was checked - my stuff is all packed away now so can’t check just yet
I’m out of ideas then (apart swapping cables and checking MIDI out settings on Cobalt)
maybe try to document your setup and post a new Support topic on this: sounds like a question for @Giedrius !
1 Like
ill spend some proper time with it before I contact support - maybe my cobalt MIDI settings are the issue - i have a bunch of family and friends in town so I’ve just been working on the pipe distractedly here and there - next week I’ll try actually working with it and i’ll hopefully figure out what’s going on
In this particular example of the properties, Argument 1 is not used at all, as it’s not referred to from the "Set XX to YY’ properties. The Argument 1 and 2 can be treated as MIDI mappable variables, that you can use for values produced by the Transform pipe when its operating conditions are met.
The CC#1 is usually dedicated to the Mod Wheel MSB, and CC#2 is the Breath controller, the reason the pipes default to CC#3 is because it’s the first officially unassigned value, so can be used for custom purposes. 
When you have the time, please create a dedicated topic to investigate the issue, please include screenshots of the entire editor window, and focus on monitoring the Input pipes first, as they don’t have any filters applied yet, so if you see DIN-5 MIDI activity LED blink at the input side, you should see the messages when selecting the matching input pipe.
2 Likes