No, pressing the same button (GoSelectedTrackFXMenu) again, returns just the local surface Home (you added this, complete with indicator, because it's more natural to press the same button again to leave the sends/receive/FX)
You can, of course, press Home, but these days that's the nuclear option (such is CSI's state of refinement) complete with seismic fader twitch
Oh right, THAT behaviour, seems it's hard to keep up these days, there are so many ways of doing things
So, that has the unwanted side effect that you can't leave an FX Slot Zone and go back to FXMenu by calling GoSelectedTrackFXMenu from the FX Slot Zone, you will always end up Home.
Maybe we need a LeaveFXSlotZone with the ability to broadcast and receive, such is the 2 step nature of FXMenu Zones.
__________________
To install you need the CSI Software and Support Files
For installation instructions and documentation see the Wiki
Donate -- via PayPal to waddingtongeoff@gmail.com
Last edited by Geoff Waddington; 07-05-2022 at 04:38 PM.
I tried @pucks OSC Page test. It goes to Page#2 and the buttons work and the displays change, but you can't return to Page#1, using either GoPage or NextPage.
I tried @pucks OSC Page test. It goes to Page#2 and the buttons work and the displays change, but you can't return to Page#1, using either GoPage or NextPage.
Do Pages still work properly in Midi Surfaces ?
__________________
To install you need the CSI Software and Support Files
For installation instructions and documentation see the Wiki
Donate -- via PayPal to waddingtongeoff@gmail.com
I just tried out SubZones out with a plugin in FX Slot 2 and they were controlling the intended FX Slot, rather than the FX mapped to Slot 1. So that looks to be resolved. Again.
I just tried out SubZones out with a plugin in FX Slot 2 and they were controlling the intended FX Slot, rather than the FX mapped to Slot 1. So that looks to be resolved. Again.
Cool, until next time folks...
__________________
To install you need the CSI Software and Support Files
For installation instructions and documentation see the Wiki
Donate -- via PayPal to waddingtongeoff@gmail.com
And for broadcast and receive the entries would be:
FocusedFXZones
SelectedTrackFXZones
FxSlotZones
What do you think ?
__________________
To install you need the CSI Software and Support Files
For installation instructions and documentation see the Wiki
Donate -- via PayPal to waddingtongeoff@gmail.com
(this is where Geoff points out I can't read)
Try that and see what happens.
LOL that's all in jest.
......
OK this is beyond strange. You were right to change the actions because it points out something. I'm not sure what that something is, however. Let me explain:
Same as before, sort of, you NextPage to Page2 and all is well.
Going back to page 1 actually does make the buttons function. None of the strings get updated though. So I can swap back and forth between pages and you can FF/REW on one page and Play/Stop on the other. It just doesn't appear to change because the strings aren't changing (after the switch from page1 to page 2, that time the strings do upate)
.....
Something I found to be really strange is what happens on initialization , or when you reset all surfaces. This is the log from TouchOSC, so it's what CSI is sending out. Note most things get sent two 0 floats and an empty string. Is that normal?
edit: Shoot I forgot to mention something you may need to fix.
If the project is playing on Page1, switching to Page2 makes the project both FF (moving the edit cursor) and Play (playhead is still playing and play is lit up) i.e. the button state persists and runs whatever action is tied to it when you change pages.
What seems to happen on both MIDI and OSC (at least when using both in tandem via broadcast/receive) is that you actually do go back to Page1, but that's not showing up in the OSC device or the MIDI feedback.
Here's what I did:
1. Loaded a new project - my HomePage has an FXMenu zone
2. Created a new track added some FX
Result: saw the FX in the FXMenu
3. Changed page to the FocusedFXZone with no FX Menu (wouldn't do this in CSI v2 other than to test)
Result: all good
4. Focused an FX - everything still worked as expected
5. Now, did a GoPage "HomePage"
Result: the OSC display and MIDI device were all showing the feedback for the mapped FX
6. Next, on the MIDI surface, I hit the button assigned to "GoFXSlot1", even though there was no indication the FXMenu page was the active one
Result: the FX in Slot 1 was mapped, but I was still seeing the feedback for the FocusedFXpage with no FX menu
7. Then I did a "GoHome"
Result: everything returned to normal
Short explanation: it appears CSI is changing back to the first page, but the feedback/displays are not updating to reflect that so it looks like you're on the second page. Until you GoHome, then it fixes it.
OK this is beyond strange. You were right to change the actions because it points out something. I'm not sure what that something is, however. Let me explain:
Same as before, sort of, you NextPage to Page2 and all is well.
Going back to page 1 actually does make the buttons function. None of the strings get updated though. So I can swap back and forth between pages and you can FF/REW on one page and Play/Stop on the other. It just doesn't appear to change because the strings aren't changing (after the switch from page1 to page 2, that time the strings do upate)
.....
Something I found to be really strange is what happens on initialization , or when you reset all surfaces. This is the log from TouchOSC, so it's what CSI is sending out. Note most things get sent two 0 floats and an empty string. Is that normal?
edit: Shoot I forgot to mention something you may need to fix.
If the project is playing on Page1, switching to Page2 makes the project both FF (moving the edit cursor) and Play (playhead is still playing and play is lit up) i.e. the button state persists and runs whatever action is tied to it when you change pages.
After you return to Page1, GoHome. Does that fix Page1?
OK this is beyond strange. You were right to change the actions because it points out something. I'm not sure what that something is, however. Let me explain:
Same as before, sort of, you NextPage to Page2 and all is well.
Going back to page 1 actually does make the buttons function. None of the strings get updated though. So I can swap back and forth between pages and you can FF/REW on one page and Play/Stop on the other. It just doesn't appear to change because the strings aren't changing (after the switch from page1 to page 2, that time the strings do upate)
.....
Aha, now we have solved the problem !!
The Page switch is working fine.
Remember how CSI doesn't send out redundant data to cut down on using bandwidth needlessly ?
When you are on Page 1 the Display Widget sends out "Page 1" once only, all good.
When you switch to Page 2 the Display Widget sends out "Page 2" once only, all good.
When you switch back to Page 1 the Display Widget sends out... wait for it... nothing... because it already sent out "Page 1" and nothing has changed from its perspective, it doesn't know about Page changes.
Just like we had to force the Widgets to clear to fix that bug a couple of days ago, we will have to force the Widgets to update on a Page change, even if the Widgets think nothing has changed
I'll get working on that.
Quote:
Originally Posted by Puck
Something I found to be really strange is what happens on initialization , or when you reset all surfaces. This is the log from TouchOSC, so it's what CSI is sending out. Note most things get sent two 0 floats and an empty string. Is that normal?
That's normal, a reset is a very heavy hammer, it sets EVERYTHING to zero
__________________
To install you need the CSI Software and Support Files
For installation instructions and documentation see the Wiki
Donate -- via PayPal to waddingtongeoff@gmail.com
edit: Shoot I forgot to mention something you may need to fix.
If the project is playing on Page1, switching to Page2 makes the project both FF (moving the edit cursor) and Play (playhead is still playing and play is lit up) i.e. the button state persists and runs whatever action is tied to it when you change pages.
Yeah, that's technically a bug, but I doubt anyone would ever alter the Transport behaviour Page to Page, that's not really what Pages are for.
__________________
To install you need the CSI Software and Support Files
For installation instructions and documentation see the Wiki
Donate -- via PayPal to waddingtongeoff@gmail.com
Oh right, THAT behaviour, seems it's hard to keep up these days, there are so many ways of doing things
....and that's a good thing
Quote:
So, that has the unwanted side effect that you can't leave an FX Slot Zone and go back to FXMenu by calling GoSelectedTrackFXMenu from the FX Slot Zone, you will always end up Home.
Yeah you can, that's what happens locally. If you're in an FXZone and you press GoSelectedTrackFXMenu, you go to the FXMenu. Press it again and you go Home.
Quote:
Maybe we need a LeaveFXSlotZone with the ability to broadcast and receive, such is the 2 step nature of FXMenu Zones.
Perhaps, but one thing crossed my mind. If you were to split the Broadcast/Receive behaviour of GoFXSlot away from GoSelectedTrackFXMenu (at the moment they're combined) you'd be able to map different FX from the same track to different surfaces.
In @MT4U's case, this would be: one FX on the X-Touch and one FX on the extender. You'd be able to do this because even though the surfaces are sharing a common FXMenu (same selected track) that doesn't mean you can't make different selections from that menu and have different FX map to different surfaces at the same time.
The other thing this independence offers is a more flexible way of spreading FX parameters across surfaces. Rather than have distinct FX.zon files for each surface to decide how the parameters are going to be split up, just use the same files with the parameters divided up into SubZones. Then open the same FXSlot on each surface , but navigate to different SubZones on each. Bingo! different parameters from the same FX spread across two surfaces. I do this all the time with my two, IncludedZone, C4s. Works great!
Aha, now we have solved the problem !!
because it already sent out "Page 1" and nothing has changed from its perspective, it doesn't know about Page changes.
Just like we had to force the Widgets to clear to fix that bug a couple of days ago, we will have to force the Widgets to update on a Page change, even if the Widgets think nothing has changed
Glad we got to the heart of the issue! Very impressed with your deduction skills based on these bug reports! It makes sense now that I hear the reason of course.
Quote:
Originally Posted by Geoff Waddington
Yeah, that's technically a bug, but I doubt anyone would ever alter the Transport behaviour Page to Page, that's not really what Pages are for.
For this though, I can imagine other problems that may arise. Say I'm in the TrackSend associated zone and it's button is on as a result of being in the zone, whatever action I decide to map to that button on another page will fire whether I want it to or not.
Yeah you can, that's what happens locally. If you're in an FXZone and you press GoSelectedTrackFXMenu, you go to the FXMenu. Press it again and you go Home.
Perhaps, but one thing crossed my mind. If you were to split the Broadcast/Receive behaviour of GoFXSlot away from GoSelectedTrackFXMenu (at the moment they're combined) you'd be able to map different FX from the same track to different surfaces.
In @MT4U's case, this would be: one FX on the X-Touch and one FX on the extender. You'd be able to do this because even though the surfaces are sharing a common FXMenu (same selected track) that doesn't mean you can't make different selections from that menu and have different FX map to different surfaces at the same time.
The other thing this independence offers is a more flexible way of spreading FX parameters across surfaces. Rather than have distinct FX.zon files for each surface to decide how the parameters are going to be split up, just use the same files with the parameters divided up into SubZones. Then open the same FXSlot on each surface , but navigate to different SubZones on each. Bingo! different parameters from the same FX spread across two surfaces. I do this all the time with my two, IncludedZone, C4s. Works great!
That's why I was adamant about getting the new architecture in place, thanks everyone for the patience.
There is a whole new world of fun to be had going forward
__________________
To install you need the CSI Software and Support Files
For installation instructions and documentation see the Wiki
Donate -- via PayPal to waddingtongeoff@gmail.com
Glad we got to the heart of the issue! Very impressed with your deduction skills based on these bug reports! It makes sense now that I hear the reason of course.
Haha, mostly it's just from having broken things so many different ways over the years
Quote:
Originally Posted by Puck
For this though, I can imagine other problems that may arise. Say I'm in the TrackSend associated zone and it's button is on as a result of being in the zone, whatever action I decide to map to that button on another page will fire whether I want it to or not.
That shouldn't be a problem.
Part of the Page switch regime should be to zero all Widgets initially on the switch.
__________________
To install you need the CSI Software and Support Files
For installation instructions and documentation see the Wiki
Donate -- via PayPal to waddingtongeoff@gmail.com
Part of the Page switch regime should be to zero all Widgets initially on the switch.
That's what I was trying to say, though. With the play button feedback on, CSI fired the action on the next page because the button was on. So currently the widgets do not zero on the switch. Unless you're saying you see that and that you plan on fixing it. In which case, as you were.
So what's actually happening (I think!) is if say you FF and then switch to another page and back again it will still FF. Because I could get it to REW if I was switching back and forth and that's not the same button. I'd still say this is funky somehow haha but I can't put my finger on it.
You can try inverting it somehow in TouchOSC. I have a couple ideas but rather than sending you down a rabbit hole I’ll try some stuff on my own and reply back if I have a solution. Not having feedback bothers me
(It only bothers me because CSI makes things so tightly integrated that it’s a shame when it’s not)
Finally make the TouchOSC panner to receive feedback! Also fixed UI. X axis messages now send reversed with "1 - x" script
Last edited by strangy; 07-05-2022 at 08:22 PM.
Reason: attaching files
Yeah you can, that's what happens locally. If you're in an FXZone and you press GoSelectedTrackFXMenu, you go to the FXMenu. Press it again and you go Home.
In my case it's the other way around. I have to call GoSelectedTrackFXMenu twice to go Home and then back to the SelectedTrackFXMenu.
I'm assuming here:
ClearFxSlotZones -> Leave the Mapped FX Zone and go back to the FX Menu?
Where would these two take you?
ClearSelectedTrackFXZones
ClearFocusedFXZones
They don't really take you anywhere, they just uncover whatever is beneath them
CSI has a Zone hierarchy.
FocusedFXParameter
FocusedFXZone
SelectedTrackFXZones
FXSlotZones
AssociatedZones
Home
For instance, let's say you activate an AssociatedZone.
Let's say the AssociatedZone maps Widget1 to some Action.
Let's say Widget1 is mapped to some other Action in Home.
Widget1 will now perform the AssociatedZone Action because the AssociatedZone "covers" or "hides" the Widget1 Action in Home since AssociatedZones are above Home in the hierarchy.
Now let's say you activate an FXSlotZone that contains a mapping for Widget1.
Now Widget1 will perform the FXSlotZone Action because the FXSlotZone "covers" both the AssociatedZone and Home.
So, in this case ClearFxSlotZones will take you back to the AssociatedZone, it will, in effect, "uncover" the Widget1 Action in the AssociatedZone.
So clearing "takes you back" to whatever Zone the clearing "uncovers".
Make sense ?
__________________
To install you need the CSI Software and Support Files
For installation instructions and documentation see the Wiki
Donate -- via PayPal to waddingtongeoff@gmail.com
Let's talk seismic Fader twitch -- love that one MixMonkey
It is distracting, not to mention stressful on the motors.
Believe it or not, this happens because you cannot query a Surface for the current Fader value.
WTF you say ?
I know, seems weird, but here's what really happens.
When you move a Fader the Surface sends a Midi message.
The Surface does not remember what it sent.
CSI receives the value, and it can remember that value, but CSI remembers it in a Page context.
When you switch Pages, CSI has to assume everything is now at zero, because it has no clue where the Fader actually is right now.
This is the effect you are referring to Puck, with Rewind, FF, Play, etc..
Well, you say, it's easy, CSI just has to pass the current Fader value from the Page we are leaving to the Page we are entering.
That would be nice
But hold on, don't forget Pages allow for different .mst/.ost files.
There is no guarantee said Fader even exists in the Page we are leaving.
There seems to be no way out of this dilemma.
Well, there wasn't... until now...
Enter our new CSI.ini format
The new structure will allow us to keep current values of any hardware component (e.g. Fader) in the hardware part of the Surface definition, and THAT can be passed on to the startup code for the Page switch, since it is Page agnostic.
This has repercussions elsewhere in CSI, anywhere you now experience the "seismic Fader twitch".
Have to work through the details, but this is definitely something that will happen down the road.
I knew I was going to like the new separation between the hardware and software parts of the Surface definition
__________________
To install you need the CSI Software and Support Files
For installation instructions and documentation see the Wiki
Donate -- via PayPal to waddingtongeoff@gmail.com
It would be great to smooth out those X-Touch faders. It's a little loud and distracting to hear the faders stuttering.
Not sure if this would be useful to you, but someone else posted a workaround that involved a loopback driver and their explanation indicated that they needed to do some linear interpolation of the pitchbend messages at a rate of around 7ms to smooth things out.
Quote:
I use Studio One V2 in this instance, but Reaper is the same. You can adjust the Hz which the data is sent from Reaper, but it will never be good, since it floods the X-Touch with other data (channel data etc) at the same frequency. I assume this causes the X-Touch to spend some processor time updating the displays instead of the fader, and will cause microstuttering on the fader.
My app is written in C++, and it does linear interpolation of the pitch bend data to the fader, and sends the actual data last, which just fills in the blanks @ 7 ms intervals. This seems to be the best so far, but it's not entirely perfect when dealing with a lot of changes (which can happen in automation).
In my case it's the other way around. I have to call GoSelectedTrackFXMenu twice to go Home and then back to the SelectedTrackFXMenu.
That's interesting, the first press doesn't take you to the FXMenu? (only on the main unit)
Anyway, we do need a broadcastable command to do this. I'm assuming that Geoff's proposed ClearFXSlotZone will simply removed the mapped FXSlot parameters and reveal the FXMenu again.
They don't really take you anywhere, they just uncover whatever is beneath them
CSI has a Zone hierarchy.
FocusedFXParameter
FocusedFXZone
SelectedTrackFXZones
FXSlotZones
AssociatedZones
Home
For instance, let's say you activate an AssociatedZone.
Let's say the AssociatedZone maps Widget1 to some Action.
Let's say Widget1 is mapped to some other Action in Home.
Widget1 will now perform the AssociatedZone Action because the AssociatedZone "covers" or "hides" the Widget1 Action in Home since AssociatedZones are above Home in the hierarchy.
Now let's say you activate an FXSlotZone that contains a mapping for Widget1.
Now Widget1 will perform the FXSlotZone Action because the FXSlotZone "covers" both the AssociatedZone and Home.
So, in this case ClearFxSlotZones will take you back to the AssociatedZone, it will, in effect, "uncover" the Widget1 Action in the AssociatedZone.
So clearing "takes you back" to whatever Zone the clearing "uncovers".
Make sense ?
Understood.
So, in the case of FocusedFXMenu, after entering an FX Slot, ClearFXSlotZone would take us back to the FocusedFXMenu. The other two would act in other situations, and these woulde be Broadcasted/Received.
That's interesting, the first press doesn't take you to the FXMenu? (only on the main unit)
Anyway, we do need a broadcastable command to do this. I'm assuming that Geoff's proposed ClearFXSlotZone will simply removed the mapped FXSlot parameters and reveal the FXMenu again.
Understood.
So, in the case of FocusedFXMenu, after entering an FX Slot, ClearFXSlotZone would take us back to the FocusedFXMenu. The other two would act in other situations, and these woulde be Broadcasted/Received.
Let's talk seismic Fader twitch -- love that one MixMonkey
It is distracting, not to mention stressful on the motors.
Believe it or not, this happens because you cannot query a Surface for the current Fader value.
WTF you say ?
I know, seems weird, but here's what really happens.
When you move a Fader the Surface sends a Midi message.
The Surface does not remember what it sent.
CSI receives the value, and it can remember that value, but CSI remembers it in a Page context.
When you switch Pages, CSI has to assume everything is now at zero, because it has no clue where the Fader actually is right now.
This is the effect you are referring to Puck, with Rewind, FF, Play, etc..
Well, you say, it's easy, CSI just has to pass the current Fader value from the Page we are leaving to the Page we are entering.
That would be nice
But hold on, don't forget Pages allow for different .mst/.ost files.
There is no guarantee said Fader even exists in the Page we are leaving.
There seems to be no way out of this dilemma.
Well, there wasn't... until now...
Enter our new CSI.ini format
The new structure will allow us to keep current values of any hardware component (e.g. Fader) in the hardware part of the Surface definition, and THAT can be passed on to the startup code for the Page switch, since it is Page agnostic.
This has repercussions elsewhere in CSI, anywhere you now experience the "seismic Fader twitch".
Have to work through the details, but this is definitely something that will happen down the road.
I knew I was going to like the new separation between the hardware and software parts of the Surface definition
It opens up to many possibilities.
I see the Fader twitch happen from time to time. Especially when I map an FX menu and then go back Home.
I have an EQ button on the X-Touch that runs a script that searches my FX chain for a list of EQs and if none is found, then inserts my default one, then it maps the FX parameters to the Encoders, configuring the Faders as Gain, so when I go back Home there is Fader realignment.
In the case of the compressors, I don't map the Faders, so there would be no need for Fader realignment.
I am working on the Config panel and revamped how CSI writes the file for a bit more clarity, might want to include this format at some point - it's just a few strategically placed blank lines, but I think it makes it a bit more readable:
__________________
To install you need the CSI Software and Support Files
For installation instructions and documentation see the Wiki
Donate -- via PayPal to waddingtongeoff@gmail.com
I am working on the Config panel and revamped how CSI writes the file for a bit more clarity, might want to include this format at some point - it's just a few strategically placed blank lines, but I think it makes it a bit more readable:
This is telling CSI that there is an OSC surface that the user has named "iPad Pro", and that receives on port 8000, transmits on port 9000, and that iPad Pro has an IP Address of 10.0.0.146.
Next up on Wiki 2.0: Message Generators. Previously, this page listed the types of message generators, then linked to a bunch of individual pages with the details for each type. Now, those secondary pages have been consolidated into the message generators page itself.
Next up on Wiki 2.0: Message Generators. Previously, this page listed the types of message generators, then linked to a bunch of individual pages with the details for each type. Now, those secondary pages have been consolidated into the message generators page itself.
Next up on Wiki 2.0: Message Generators. Previously, this page listed the types of message generators, then linked to a bunch of individual pages with the details for each type. Now, those secondary pages have been consolidated into the message generators page itself.
The man was a true poet philosopher 
Linear Mode
