Signal Flow Reference

[William W. Saunders, Jr.]

On 11/15/2020 at 7:11 AM, tparker24 said:

There are also several other items involved, like: clip FX,   Key+, Vel+,  and the  new articulations maps. 

It would be very helpful to have a signal flow diagram to show the paths and the interactions.

Ahh, I hadn't considered that since I haven't been using those.

[riecke]

I just found this thread in my own search for a midi signal flow chart.  
 

I can't find one.  I'm going to put in a support request.  
 

[John Vere]

I myself don't understand why you would need such an item? I've been using Midi for a million years and it has never changed much since day one in the 80's. 

It's data. That data flows to an instrument where it becomes audio and from there on is treated like any audio. This could be a VST instrument or a Hardware instrument (or a Lighting rig or a smoke pot. ) 

You can manipulate that data on it's way to the instrument in a zillion weird ways with controllers and other data that is added to the data stream. The common ways are CC events ( CC7 ) and system exclusive data packages. 

A midi signal flow chart will be a straight line with little boxes added in the path where you alter the original data. 

[bvideo]

30 minutes ago, John Vere said:

I myself don't understand why you would need such an item? I've been using Midi for a million years and it has never changed much since day one in the 80's. 

It's data. That data flows to an instrument where it becomes audio and from there on is treated like any audio. This could be a VST instrument or a Hardware instrument (or a Lighting rig or a smoke pot. ) 

You can manipulate that data on it's way to the instrument in a zillion weird ways with controllers and other data that is added to the data stream. The common ways are CC events ( CC7 ) and system exclusive data packages. 

A midi signal flow chart will be a straight line with little boxes added in the path where you alter the original data. 

A straight line with boxes would not be able to explain anomalies in the mute & solo & input echo parts of the MIDI signal flow or how prerecorded material merges with live input or the entanglements with instrument tracks and their synth components.

[Glenn Stanton]

there are definitely some things where  a MIDI flow would help - such as relationships with Devices -> None, Omni, and Auto-Thu, etc  which could help as well

[user 905133]

2 hours ago, John Vere said:

I myself don't understand why you would need such an item? I've been using Midi for a million years and it has never changed much since day one in the 80's. 

It's data. That data flows to an instrument where it becomes audio and from there on is treated like any audio. This could be a VST instrument or a Hardware instrument (or a Lighting rig or a smoke pot. ) 

You can manipulate that data on it's way to the instrument in a zillion weird ways with controllers and other data that is added to the data stream. The common ways are CC events ( CC7 ) and system exclusive data packages. 

A midi signal flow chart will be a straight line with little boxes added in the path where you alter the original data. 

You might not understand but that doesn't mean that others wouldn't find it useful.  There are problems in CbB because the flow of MIDI data doesn't seem to work in some circumstances and for those of us who haven't given up, it would be helpful to know what CbB is doing with MIDI data under the hood.

One example:  MIDI Remote Control doesn't work with the Inspector-based Arpeggiator.  It would be nice to see the alleged flow to determine if its a bug or if CbB is doing something that users don't know about.

Edited June 12, 2021 by User 905133

[scook]

I am all for documentation. Signal and data flow diagrams are useful.

There are a few assumptions about what a MIDI signal flow diagram would show. 

The request for additional documentation and the discussion about what needs to be documented are subjects for the feedback section. It really has nothing to do with the OP which reproduced the signal flow diagram already in the documentation.

This part of the forum was created to discuss the software as it exists.

Answers not found in the documentation should be posed here.

 

WRT input echo, it is unclear how much detail about the rules for setting input would be encapsulated in a diagram.

The subject of how input echo affects input settings has been discussed at length.

"Auto-thru" is an indication that the Always Echo Current MIDI Track in preferences in enabled. 

Whether enabled by the "Always Echo" preference setting or manually, input echo requires the track input be set to a value other than None. Historically, this mean tracks originally set to None would be set to Omni when input echo was enabled. Recently, this has changed. If a project has no plug-ins with "Enable MIDI Output" turned on, the historical setting to Omni is still used. If there are any plug-in with "Enable MIDI Output" turned on and an instrument/MIDI track has its input set to None and input echo get enabled, the input changes to "All External Inputs Omni". This change was made in an attempt to avoid accidently monitoring/recording MIDI data coming from plug-ins.

 

Not sure remote control would show up in a MIDI signal flow diagram it is not part of the data processed by the MIDI input. It is part of the external control system like control surfaces and ACT.

[user 905133]

40 minutes ago, scook said:

The request for additional documentation and the discussion about what needs to be documented are subjects for the feedback section. It really has nothing to do with the OP which reproduced the signal flow diagram already in the documentation.

I remember feeling this way back in November (hence my minimalist initial reply back then and my subsequent choice not to engage in a the discussion of others) and I still agree that any discussion of the possible benefits of a midi data flow chart within Cakewalk belongs in its own thread.  I am surprised that no one opened up a discussion in another thread or put in a request between then and now.  (I thought I had, but I might have decided not to.)

40 minutes ago, scook said:

Not sure remote control would show up in a MIDI signal flow diagram it is not part of the data processed by the MIDI input. It is part of the external control system like control surfaces and ACT.

As for me, I decided months ago to give up on the idea that the remote control functionality in the Inspector-based Arpeggiator would either be explained or fixed.  But this is not the thread to discuss that issue.  I was just offering a simple example off the top of my head as to where a midi signal flow might be helpful. 

 

Edited June 12, 2021 by User 905133
(2) to add a detail about why I didn't continue the discussion in November 2020; (1) to fix a typo

[riecke]

I just found this thread in my own search for a midi signal flow chart.  
 

I can't find one.  I'm going to put in a support request.  

Well... I got an answer back from Support.  They don't have documentation of MIDI signal flow in Cakewalk.  They sent me a link to MIDI mapping, which is only available in the web app (which I don't use).  Also, it's not what I asked for.  
 

Also...  it doesn't matter why I want it.  Software should be documented and when I get it, if I ever do, I am capable of determining  whether or not I can use it.
 

 

[Jim Fogle]

On 6/12/2021 at 10:54 AM, riecke said:

I just found this thread in my own search for a midi signal flow chart.  
 

I can't find one.  I'm going to put in a support request.  
 

Please post a link to your request so I can add my support of your request.

[winkpain]

Where exactly in the signal flow should we consider a live audio source (from hardware input, soft synth, or patch point in the image)  to be "printed to tape", so to speak, onto it's track?  Would it be at the point of the upper red arrow in the image below , or the lower one?

It seems to be the upper one. This always causes a bit of confusion for me, as the "Input Gain" that falls between those two points doesn't effect what gets  live recorded, either from a hardware input or soft synth (being recorded live) or patch point.  Or should we rather think of live input during recording as falling outside of this flow, going directly from the audio card (in the case of hardware input) to the tape (or track in CbB) ?  The confusion for me is "Input Gain" makes me think gain on an input (live input) like a pre-amp , but it's really gain on the "input" from tape (track) which, to me, is more of an "output". 

Clarifications?

[Glenn Stanton]

it's definitely different than a HW gear where input gain would control the gain on the physical live audio, and the audio from a "tape unit" would (unless patched otherwise) bypass that gain control. so in the example, yes, the track input gain is only used to control the recorded clip and the live input would have be controlled on the HW IO. i don't see it as an output gain since it's at the beginning of the track path.

what is a bummer is that the patch point and soft synth bypass the input gain as it would seem useful that controlling the gain from a patch point (summing possible there) or soft synth (generally 1:1 on outputs to inputs) to prevent the input of a track from overloading, whereas it seems that you would have to manipulate the tracks outputting to the patch point (or at the soft synth) to achieve a usable level on the track using it as an input. 

[winkpain]

20 minutes ago, Glenn Stanton said:

what is a bummer is that the patch point and soft synth bypass the input gain as it would seem useful that controlling the gain from a patch point (summing possible there) or soft synth (generally 1:1 on outputs to inputs) to prevent the input of a track from overloading, whereas it seems that you would have to manipulate the tracks outputting to the patch point (or at the soft synth) to achieve a usable level on the track using it as an input. 

Yes, it is in this way that I wished to use it (Input Gain control) with a Patch Point, as a summing gain for controlling recording level in certain instances. What is odd is that, in the Signal Flow diagram, it shows patch points and soft synths as flowing into the Input Gain as opposed to hardware inputs falling after it. But again, where does the tape/track lie in that chart when it's in record mode?  My upper red arrow, right? (but with the hardware input flowing through it as well)

Edited June 13, 2021 by winkpain

[winkpain]

On 6/13/2021 at 5:40 PM, Glenn Stanton said:

yes, the track input gain is only used to control the recorded clip and the live input would have be controlled on the HW IO

 

On 6/13/2021 at 5:40 PM, Glenn Stanton said:

what is a bummer is that the patch point and soft synth bypass the input gain

SO... I am still scratching my head on how to really understand the signal flow indicated in the above chart, specifically where it seems to indicate that the Soft Synth and Patch Point signals indeed come before the Input Gain control as marked with my upper red arrow. In my (perhaps just wishful thinking) desire for what is shown in this chart to be true and that using a Patch Point would allow actual input gain control over a live signal (that is otherwise at a fixed level) before being recorded, I have been trying things and have noticed very odd (to my understanding) behavior...

1. As a test, I first tried playing a soft synth live while record enabling its associated audio track only and varying the Input Gain from -18 to +18db throughout the recording process. The audio I heard while recording changed with these gain variations, and the waveform that displayed while recording clearly showed the gain variations as well. Immediately upon stopping recording, however, the waveform reverted to a consistent unity gain display and the playback did likewise. 
2. I then tried patching this same Soft Synth's audio track to a Patch Point, record enabling this track only and repeated the procedure varying the Input Gain on the original audio track (of the synth), and this resulted in a gain varied clip being recorded on the Patch Point track. (This, of course, can be achieved with varying the track fader of the original synth audio track as well or a combo of Input Gain and track fader.  - Varying the Patch Point's Input Gain during recording made no difference, as in #1)
3. Then, changing nothing but the input source of the original audio track to a hardware input and leaving that track patched to the Patch Point set to record, I recorded audio while varying the Input Gain control of the original audio track exactly as in test #2. Unlike in test #2 however,  this had no effect on the recorded clip. (Varying the track fader did vary the recorded level as desired.)

 

What, then is the difference between # 2 and # 3? In my mind they should have had the same result. There is obviously something nuanced in the signal flow going on in the variations between these examples that is not being explained, certainly not in the signal  flow chart above.  I understand and see that a hardware input is indeed bypassing the Input Gain and this is indicated in the chart where I have the lower red arrow. But the Soft Synth/Patch Point signal line shows then arriving above/before the Input Gain. And why does a Patch Point behave differently to the Input Gain of its source track if it's receiving audio from a synth as opposed to audio from hardware ? In both cases, the Patch Point is just receiving audio from an audio track. How does the Patch Point track "know" that there is a difference between the original sources of the audio??

 

 

Edited September 18, 2021 by winkpain

[Glenn Stanton]

21 hours ago, winkpain said:

SO... I am still scratching my head on how to really understand the signal flow indicated in the above chart, specifically where it seems to indicate that the Soft Synth and Patch Point signals indeed come before the Input Gain control as marked with my upper red arrow.

...

Immediately upon stopping recording, however, the waveform reverted to a consistent unity gain display and the playback did likewise.

i'm thinking the #2-3 is akin to "bounce to track" effect where the (apparently temporary nature of the gain control) is effecting the level. my guess - the soft synth output is being written to a temp memory queue or temp file while recording it and so its acting like a clip input, it has that level adjustment, but once done, the proper clip file is written, it's written as unity gain as noted. so when recording it from a patch point, which is receiving the gain variations, it does actually record that.

my guess is we need an updated flow diagram ? and/or perhaps letting the gain level work on inbound audio regardless of source... (which is likely what the majority of folks would expect).

[winkpain]

5 minutes ago, Glenn Stanton said:

letting the gain level work on inbound audio regardless of source... (which is likely what the majority of folks would expect).

Absolutely!