Go Back   Cockos Incorporated Forums > REAPER Forums > REAPER Feature Requests

Reply
 
Thread Tools Display Modes
Old 08-05-2013, 12:31 PM   #161
airon
Human being with feelings
 
airon's Avatar
 
Join Date: Aug 2006
Location: Berlin
Posts: 11,817
Default


v38

Added graphical documentation. This will be further developed.

I may just upload a PDF for the full request. This is easier to maintain than a forum post.




__________________
Using Latch Preview (Video) - Faderport 16 setup for CSI 1.1 , CSI 3.10
Website
"My ego comes pre-shrunk" - Randy Thom
airon is offline   Reply With Quote
Old 08-06-2013, 02:26 AM   #162
airon
Human being with feelings
 
airon's Avatar
 
Join Date: Aug 2006
Location: Berlin
Posts: 11,817
Default

v39 - Condensed down to main panels

Added detailed documentation via a 500 KB PDF file.



--->> PDF of panel description <<---




__________________
Using Latch Preview (Video) - Faderport 16 setup for CSI 1.1 , CSI 3.10
Website
"My ego comes pre-shrunk" - Randy Thom

Last edited by airon; 08-06-2013 at 05:13 AM.
airon is offline   Reply With Quote
Old 08-08-2013, 02:07 AM   #163
airon
Human being with feelings
 
airon's Avatar
 
Join Date: Aug 2006
Location: Berlin
Posts: 11,817
Default

Time to start thinking about how to store Capture and State buffers in the project bay, and whether a Pass buffer should be savable as well.


There are two automation logs proposed here.
  1. The Commit log.
    Commits are the method of applying the data in one of the buffers, be it a State or a Pass, to the envelopes of the tracks in the session.

    This is like an undo history for automation. It documents every commit action and lets you recall and apply that commit in any other place you like. You simply load the entry back in to either the State or Capture buffer, and do with it as you please.

    Each commit log entry should also be nameable and display vital information on what tracks were commited to.
    • What - Which of the envelope categories did it contain ?
    • When - What was the time of the commit ?
    • Where - At what timecodes in the session was the commit made ?
  2. The Snapshot section
    This could be a standalone view, a section in the project bay or a section of the automation panel that opens up from a button/action actiovation.

    All the buffer contents that the user wants to hold on to and wishes to give proper names are placed in the Snapshot section.

    This section could also double as a global preset manager for all plugins. Presets could be extracted from the snapshots, if possible and placed inside the preset library.

    In a sense, the snapshot section could thus be part of a library system, similar to the Resources window of the SWS extension.



Comments ?

__________________
Using Latch Preview (Video) - Faderport 16 setup for CSI 1.1 , CSI 3.10
Website
"My ego comes pre-shrunk" - Randy Thom
airon is offline   Reply With Quote
Old 08-09-2013, 08:35 AM   #164
airon
Human being with feelings
 
airon's Avatar
 
Join Date: Aug 2006
Location: Berlin
Posts: 11,817
Default

The request has been updated with better workflow graphics and a few minor tweaks here and there.

Where do you think the Commit log, which is an UNDO history for automation, should live ?

Its own view, like the undo history ?
Project bay ?
In the automation panel ?
__________________
Using Latch Preview (Video) - Faderport 16 setup for CSI 1.1 , CSI 3.10
Website
"My ego comes pre-shrunk" - Randy Thom
airon is offline   Reply With Quote
Old 08-09-2013, 09:32 AM   #165
plush2
Human being with feelings
 
Join Date: May 2006
Location: Saskatoon, Canada
Posts: 2,110
Default

Quote:
Originally Posted by airon View Post
Time to start thinking about how to store Capture and State buffers in the project bay, and whether a Pass buffer should be savable as well.


There are two automation logs proposed here.
  1. The Commit log.
    Commits are the method of applying the data in one of the buffers, be it a State or a Pass, to the envelopes of the tracks in the session.

    This is like an undo history for automation. It documents every commit action and lets you recall and apply that commit in any other place you like. You simply load the entry back in to either the State or Capture buffer, and do with it as you please.

    Each commit log entry should also be nameable and display vital information on what tracks were commited to.
    • What - Which of the envelope categories did it contain ?
    • When - What was the time of the commit ?
    • Where - At what timecodes in the session was the commit made ?
  2. The Snapshot section
    This could be a standalone view, a section in the project bay or a section of the automation panel that opens up from a button/action actiovation.

    All the buffer contents that the user wants to hold on to and wishes to give proper names are placed in the Snapshot section.

    This section could also double as a global preset manager for all plugins. Presets could be extracted from the snapshots, if possible and placed inside the preset library.

    In a sense, the snapshot section could thus be part of a library system, similar to the Resources window of the SWS extension.



Comments ?

That seems like a logical approach. The description of the two as libraries for automation data and dsp snapshots makes a lot of sense to me as someone who's never used these state buffer/capture buffer systems large scale. In short, I know exactly how I could use that.

Having them individually accessible would also help with new users adopting them into their workflow. As it stands with ie. the automation window in PT I have many colleagues who never even open it, have no idea really what it does and I think it's because it's a bit daunting...all those buttons. When I explain the write to selection feature most of them declare they would use it all the time if they knew about it. A simple interface for capturing that snapshot setting and then writing it to a selection would be much easier to grasp for new users.
plush2 is offline   Reply With Quote
Old 08-09-2013, 10:06 AM   #166
airon
Human being with feelings
 
airon's Avatar
 
Join Date: Aug 2006
Location: Berlin
Posts: 11,817
Default

That simple capture and storing that away in to the snapshot library of the session can happen with both the Capture and the State buffer.

With the Capture buffer you have to use the buttons to add stuff to the capture buffer. All but the Session button capture on a selected-track basis(plus modifier+click for session wide stuff). Easy.

The State buffer is cool because it also lets you add single parameters, unless you have the Auto-Add on. Then all active parameters from the plugin get added to the state buffer. You can even preview those values elsewhere in the session, which is why Protools and some other DAWs and consoles call it a preview mode.

The Capture log doesn't seem very hard to imagine.

The Snapshot library however is hard. No idea what that will look like.


What problems or misunderstandings do you anticipate ? It might also help to point some people at the control panel in the post above and ask them whether they can make heads or tails of it.
__________________
Using Latch Preview (Video) - Faderport 16 setup for CSI 1.1 , CSI 3.10
Website
"My ego comes pre-shrunk" - Randy Thom
airon is offline   Reply With Quote
Old 08-09-2013, 05:23 PM   #167
plush2
Human being with feelings
 
Join Date: May 2006
Location: Saskatoon, Canada
Posts: 2,110
Default

Quote:
Originally Posted by airon View Post
What problems or misunderstandings do you anticipate ? It might also help to point some people at the control panel in the post above and ask them whether they can make heads or tails of it.
I don't think the answer would be very surprising. It's a complicated idea that I hope can be simplified for new, non-control surface savvy dummies like me.

I think the read/write/view control panel will be pretty self explanatory for most. The other panel in general is very powerful once you understand it but perhaps...much like Reaper that power is confusing to some. I think the main confusion would be the seeming duplication between the state buffer and the capture buffer. There are nearly identical controls above and below with subtle differences on both sides of that panel. If I had to say anything is confusing it would be that. So, if you were forced to choose between a state buffer or a capture buffer, which would be the most versatile as a main/default option? I'm not saying I understand it well enough to say this can be done...I'm just suggesting that might be a way to simplify.
plush2 is offline   Reply With Quote
Old 08-09-2013, 05:39 PM   #168
airon
Human being with feelings
 
airon's Avatar
 
Join Date: Aug 2006
Location: Berlin
Posts: 11,817
Default

The capture buffer is actually just a temporary storage for whatever settings you want. You can't change its contents with anything but recapture, purge or loading from the Snapshot library or Capture log.


The State buffer is unbypassed, will be used during playback indead of the envelope lanes.

The capture buffer just sits there and does nothing.

This is a good point actually, and I'll try to work that in to the design, making it obvious just what these buffers do. Already have an idea.
__________________
Using Latch Preview (Video) - Faderport 16 setup for CSI 1.1 , CSI 3.10
Website
"My ego comes pre-shrunk" - Randy Thom
airon is offline   Reply With Quote
Old 08-09-2013, 07:02 PM   #169
airon
Human being with feelings
 
airon's Avatar
 
Join Date: Aug 2006
Location: Berlin
Posts: 11,817
Default



Here's the idea. Vertical stacking, clearly separating the Capture from the STate buffer, and associating the State buffer clearly with the Commit functions.

Some descriptive light text added as well. I'm thinking about moving some stuff around on the right side to connect the State mode more with the state buffer controls. Got an idea. Will upload when ready.(-edit- at the bottom of post)




Here's the second idea or rearranging the right-hand side to connect the State commit options more with the State buffer function buttons(round stuff).



__________________
Using Latch Preview (Video) - Faderport 16 setup for CSI 1.1 , CSI 3.10
Website
"My ego comes pre-shrunk" - Randy Thom

Last edited by airon; 08-09-2013 at 07:19 PM.
airon is offline   Reply With Quote
Old 08-09-2013, 09:19 PM   #170
plush2
Human being with feelings
 
Join Date: May 2006
Location: Saskatoon, Canada
Posts: 2,110
Default

This new design is much better to my eye. The vertical rows indicate to me a sort of flow rather than parallel processes. Take into account that I'm starting to understand the function of the whole thing better so that may play a factor in my perceptions.

Quote:
Originally Posted by airon View Post
The capture buffer just sits there and does nothing.
If that's the case then could the individual switches for volume, pan, send and insert be done away with? If I'm understanding correctly the capture would always be passed into the state buffer for "editing" procedures. Is there a reason (I'm sure there is ) why this would not work?
plush2 is offline   Reply With Quote
Old 08-10-2013, 06:07 AM   #171
airon
Human being with feelings
 
airon's Avatar
 
Join Date: Aug 2006
Location: Berlin
Posts: 11,817
Default

The Capture buffer is simply an independant buffer, a temp storage if you will.

If you put stuff in to the State buffer, and State mode is active, it'll take over those parameters during playback until the State buffer is emptied.

That's why you've got the commit and State buffer commands coloured yellow, and the Capture buffer buttons coloured green.


If you want to edit those values, you'd need top copy them from the Capture to the State buffer. Of course you could do the same by just adding the same values to the State buffer.

It's another slot right on the panel, and it's independant.
__________________
Using Latch Preview (Video) - Faderport 16 setup for CSI 1.1 , CSI 3.10
Website
"My ego comes pre-shrunk" - Randy Thom
airon is offline   Reply With Quote
Old 08-10-2013, 09:10 AM   #172
plush2
Human being with feelings
 
Join Date: May 2006
Location: Saskatoon, Canada
Posts: 2,110
Default

Since we have the ability in your panels to selectively arm, play and disable automation types, and we have the ability to edit captured automation of these types with the state buffer, do we really need another filter on the capture buffer? Why not just have the capture buffer capturing everything fed to it all the time?



I would suggest keeping the Track and Session buttons. The filter buttons on the State section could be made to work both ways...so they filter what is being copied from the capture buffer for adding and filter what is being written after editing.
plush2 is offline   Reply With Quote
Old 08-11-2013, 12:27 AM   #173
airon
Human being with feelings
 
airon's Avatar
 
Join Date: Aug 2006
Location: Berlin
Posts: 11,817
Default

Quote:
Originally Posted by plush2 View Post
Since we have the ability in your panels to selectively arm, play and disable automation types, and we have the ability to edit captured automation of these types with the state buffer, do we really need another filter on the capture buffer? Why not just have the capture buffer capturing everything fed to it all the time?
On the other panel, the global read switches control playback of envelopes, and the global write switches control what ultimately can be written. They don't control what you can capture in either the capture or state buffer.

I'd be using the Capture buffer to hold on to a specific bunch of settings while I mess about with others in the State buffer, such as a bunch of send levels on dialogue tracks and the plugin settings on a reverb for example.

Don't forget that the capture and preview buttons would work on a selected track basis, at least that's the idea so far. So the user could be cobbling together a new snapshot from all over the place with either the Capture or State buffer. The Capture buffer is then like an instant recall while you continue work on some other task before pulling it out for quick application.

I saw how Capture worked in Protools and didn't much like it. I wanted flexibility in what I captured where, and didn't want to compromise on what was a quick-snapshot slot in form of the Capture buffer.

Besides, adding filters for what to copy to the State buffer would complicate matters, at least as far as I can see so far. You'd need 'only copy this category'-buttons for copying of data to and from the Capture buffer.

One copy button per direction puts the burden of what is in the Capture buffer on the user, and then the capture buttons are the necessary control they need, just like they are for the State buffer. It will the users job to know what data they're storing and pulling for use. And if they're mixing, they will know.

I don't see Harrison users trying to remember what ATTention buttons they pressed on which sections of which tracks before they write data.

Besides, you have that final control filter for the act of commiting the data with the global write switches too.




Quote:
I would suggest keeping the Track and Session buttons. The filter buttons on the State section could be made to work both ways...so they filter what is being copied from the capture buffer for adding and filter what is being written after editing.
The global write switches already control what can be written, and they do it for all write operations in state and pass mode, so that would just inflate the amount of buttons on the panel or complicate the filter buttons with modifiers that do something besides capturing.

Right now the yellow capture buttons would perform selected-track operations and global ones with a modifier. They're meant to be used by beginning users to understand the process, later moving on to keyboard/control surface operation to speed everything up. The yellow State buffer buttons, all together and not individually, are also an indicator that the State buffer contains data. They are thus dark until the user performs an action that places a parameter and its value in the State buffer.

Should more complex stuff be placed here such as "Pull plugin data from the Capture buffer", that may be nice addition, but it shouldn't be replaced the simple "Copy Capture to State buffer" operation.

However, it is worth thinking about how often we'd be compositing data from two buffers. I could easily split the buttons up for copying operations on each side, but that would make it more error prone.

Also, now that I think about it, the Capture and State buffers could indicate what type of data they contain by lighting up the buttons, though they can never indicate what track it'll be from. That's still up to the user to remember.

I'll work up an example for the button split....
__________________
Using Latch Preview (Video) - Faderport 16 setup for CSI 1.1 , CSI 3.10
Website
"My ego comes pre-shrunk" - Randy Thom
airon is offline   Reply With Quote
Old 08-11-2013, 01:08 AM   #174
airon
Human being with feelings
 
airon's Avatar
 
Join Date: Aug 2006
Location: Berlin
Posts: 11,817
Default


Here's an idea for a button split, facilitating fine-grained control over copying contents of each buffer.

Maybe the Capture buffer needs a better name, but I can't think of one yet. "Store", "Temp"... Can't use Snapshot, which is pretty much what it is, but it's on the panel.

Also, one of the remaining abnormal buttons has been put in its place, the "Auto Add Plugin" button, which is actually an option. Thus it is now rectangular. Still have the envelope view buttons to do on the upper control panel.

-Edit- I'll have to change the session button back to a singular enitity for both buttons. It makes absolutely no sense to have an extra copy button for that :P .
-Edit2- Fixed. View-Envelope buttons are now rounded to indicate them being commands and not options. Also changed "ALL" to "None", since hiding is what folks may often want to do.

The lock is engaged in this version too, and is rectangular as well to indicate that it is an option. Since the lock is so important, I'm trying a strong red on this.

The lock indicates that all commit operations do not purge the commited buffer. If the lock is disengaged, every commit operation does purge the commited buffer. This readies the system for the next task.





__________________
Using Latch Preview (Video) - Faderport 16 setup for CSI 1.1 , CSI 3.10
Website
"My ego comes pre-shrunk" - Randy Thom

Last edited by airon; 08-11-2013 at 02:14 AM.
airon is offline   Reply With Quote
Old 08-11-2013, 02:34 AM   #175
airon
Human being with feelings
 
airon's Avatar
 
Join Date: Aug 2006
Location: Berlin
Posts: 11,817
Default

Here are two example workflows, one for Pass, one for State mode.
  1. Perspective changes on the same track

    Options :
    • Pass mode, if you want to ride stuff, State mode if you want to write static values
    • Time Selection option in the Pass(and/or State) mode row
    • Manual commit mode if you're going to start and stop a lot to find and change values.

    Operation
    1. Make your time selection across the area of the perspective you wish to change parameters for. In our case it might just be volume and send volume.

    2. Place the playback cursor 10-20 seconds before the time selection begins. You want to give yourself time to find the right levels. You can leave looping on or off. I prefer to start with a lot of preroll to find the values, and restart transport from that same position if I'm not happy yet.

      Sometimes it can be advantageous to decouple time selection and loop selection, so you can loop around your time selection with some pre- and post-roll.

    3. Hit play and find your values.

    4. You can still decide now whether you'd like to write static values or the complete pass across the time selection, and ONLY the time selection. Just switch to State mode. You will find the current values from the Pass buffer in it.

      Commit, and move on.

      If you'd like to apply these values, use State mode and engage the lock. Then just make time selections and commit for every area you wish to apply those values to. When you're done, disengage the lock and purge, or disengage the lock for the last commit. Remember that the commit log will let you retrieve those values again, so all is safe.

  2. Static value back to punch in (where you start touching values)

    Options:
    • State buffer
    • Write Back to Punch In option in the State buffer row.
    • On Stop mode recommended, if you're quick.



    Operation
    1. Hit play and find your values
    2. Stop transport and you're done, if On Stop mode was active.
__________________
Using Latch Preview (Video) - Faderport 16 setup for CSI 1.1 , CSI 3.10
Website
"My ego comes pre-shrunk" - Randy Thom
airon is offline   Reply With Quote
Old 08-11-2013, 09:15 AM   #176
plush2
Human being with feelings
 
Join Date: May 2006
Location: Saskatoon, Canada
Posts: 2,110
Default

That explanation makes sense to me.

Quote:
Originally Posted by airon View Post
Also, now that I think about it, the Capture and State buffers could indicate what type of data they contain by lighting up the buttons, though they can never indicate what track it'll be from. That's still up to the user to remember.
What if the automation icon on the track lit up in a corresponding way to the data that is in the Capture and State buffers...not to indicate automation in general on the track but to indicate the relationship between said track and what is currently in the buffer(s)?
plush2 is offline   Reply With Quote
Old 08-11-2013, 03:45 PM   #177
airon
Human being with feelings
 
airon's Avatar
 
Join Date: Aug 2006
Location: Berlin
Posts: 11,817
Default

The request contains a new automation button, which functions as a commit button. It indicates the presence of data in the state or pass buffer.

The request thread contains an image.
__________________
Using Latch Preview (Video) - Faderport 16 setup for CSI 1.1 , CSI 3.10
Website
"My ego comes pre-shrunk" - Randy Thom
airon is offline   Reply With Quote
Old 08-11-2013, 06:13 PM   #178
plush2
Human being with feelings
 
Join Date: May 2006
Location: Saskatoon, Canada
Posts: 2,110
Default

So I see. I haven't visited the request page in a while. :\
plush2 is offline   Reply With Quote
Old 08-11-2013, 10:10 PM   #179
airon
Human being with feelings
 
airon's Avatar
 
Join Date: Aug 2006
Location: Berlin
Posts: 11,817
Default

It's basically a mode and a yes/no-data indicator. THe context menu should give you access to relevant options for each mode.

Purging a buffer would happen via the universal ALT+click on it.

I'm not sure whether the commit function should be global on the TCP/MCP actually.

Would it make sense to you to have a track-local commit, even if it's just on the TCP/MCP ? Or shouldn't the whole thing be consistent ?

The button could indicate which track has data in the buffer of the current mode(state/pass).

And then there's the question of taking things OUT of the buffer.

If the automation button is "selected track", which the main panel COmmit is NOT and should never be, the ALT+click could empty it just for that track.

So it looks to me like there's every reason to keep it consistent, and have the per-track or rather the "Commit to selected track" stuff relegated to MODIFIER + CLICK on the button and somewhere in its context menu.

That way it could be done the same way on the larger autoamtion panel itself. Consistency, with the most-used case coming first.

That most-used case is "touch, commit, move on".
__________________
Using Latch Preview (Video) - Faderport 16 setup for CSI 1.1 , CSI 3.10
Website
"My ego comes pre-shrunk" - Randy Thom
airon is offline   Reply With Quote
Old 08-12-2013, 12:23 PM   #180
plush2
Human being with feelings
 
Join Date: May 2006
Location: Saskatoon, Canada
Posts: 2,110
Default

Quote:
Originally Posted by airon View Post
So it looks to me like there's every reason to keep it consistent, and have the per-track or rather the "Commit to selected track" stuff relegated to MODIFIER + CLICK on the button and somewhere in its context menu.
I can imagine someone flying along putting together passes from a control surface without leaving the control panel. In that case having a track selection change behavior would definitely throw a wrench into things. In addition, someone like myself would probably only use the control panel for larger changes and would trust a per track menu for the more mundane operations.

...so, yes I agree that consistent is best.
plush2 is offline   Reply With Quote
Old 08-22-2013, 08:04 PM   #181
airon
Human being with feelings
 
airon's Avatar
 
Join Date: Aug 2006
Location: Berlin
Posts: 11,817
Default

Added the last version to the request.

Thinking about the concept of adding setup slots for quick access to specific tasks such as
  • Pass mode, manual commit, time selection
  • State mode, manual commit, to punch in
  • State mode, manual commit, time selection
  • etc.

Perhaps a simple 8-slot system. People can setup their own favorute setups this way, even name them. At the very least it would provide easy access to good starting points or safeties.

The one "Reset to default" didn't seem enough.
__________________
Using Latch Preview (Video) - Faderport 16 setup for CSI 1.1 , CSI 3.10
Website
"My ego comes pre-shrunk" - Randy Thom
airon is offline   Reply With Quote
Old 11-14-2013, 05:12 AM   #182
airon
Human being with feelings
 
airon's Avatar
 
Join Date: Aug 2006
Location: Berlin
Posts: 11,817
Default

Had an idea for a radial display for the Commit options.

One commit option (Time Selection) is active.

__________________
Using Latch Preview (Video) - Faderport 16 setup for CSI 1.1 , CSI 3.10
Website
"My ego comes pre-shrunk" - Randy Thom

Last edited by airon; 11-14-2013 at 05:48 AM.
airon is offline   Reply With Quote
Old 01-05-2014, 05:35 PM   #183
airon
Human being with feelings
 
airon's Avatar
 
Join Date: Aug 2006
Location: Berlin
Posts: 11,817
Default

January 5th 2014
v44 update. Further refinement to make funciton and connection between capture & state buffer and state mode obvious, and that pass mode doesn't use those buffers.
__________________
Using Latch Preview (Video) - Faderport 16 setup for CSI 1.1 , CSI 3.10
Website
"My ego comes pre-shrunk" - Randy Thom
airon is offline   Reply With Quote
Old 04-07-2014, 12:25 AM   #184
airon
Human being with feelings
 
airon's Avatar
 
Join Date: Aug 2006
Location: Berlin
Posts: 11,817
Default

VOTE for this Feature Request in the issue tracker.

Current design - v45 (April 7th 2014)

I've decided to purge the main documentation of the request and just write down how the panel is supposed to work within the actual illustration.

Time Selection IN and OUT locations are now part of the option panel. The "Auto-Add Plugin" option has been moved to the far right, since it does not require being in a central location at all times.






__________________
Using Latch Preview (Video) - Faderport 16 setup for CSI 1.1 , CSI 3.10
Website
"My ego comes pre-shrunk" - Randy Thom
airon is offline   Reply With Quote
Old 01-26-2015, 09:03 AM   #185
hrryniu
Human being with feelings
 
Join Date: Jan 2015
Posts: 6
Default

+1 still waitin for it!
hrryniu is offline   Reply With Quote
Old 01-26-2015, 12:05 PM   #186
airon
Human being with feelings
 
airon's Avatar
 
Join Date: Aug 2006
Location: Berlin
Posts: 11,817
Default

Many mixers are.

Check out the most recent iterations in the last posts of this thread.

http://forum.cockos.com/showthread.php?t=139071

Feedback is always welcome.

Looking at it now after a while, I realize the mode switch button at the top of the panel might have a visually confusing shape.
__________________
Using Latch Preview (Video) - Faderport 16 setup for CSI 1.1 , CSI 3.10
Website
"My ego comes pre-shrunk" - Randy Thom
airon is offline   Reply With Quote
Old 01-31-2015, 07:59 PM   #187
Dbone
Human being with feelings
 
Join Date: Jan 2015
Posts: 3
Default Automation arming

I'm a newb... can't figure out how to display the Automation panel, and if I do - can I do global track arming for recording and other functions ? I've got Reaper 4.76, x64

Thanx in advance
Dbone is offline   Reply With Quote
Old 02-04-2015, 07:41 PM   #188
audio2u
Human being with feelings
 
audio2u's Avatar
 
Join Date: Dec 2010
Location: Sydney
Posts: 238
Default

Dbone,
Love the enthusiasm, but unfortunately for all of us, this is still only a Feature Request.... more's the pity.
__________________
Cheers,
Bruce.
audio2u is offline   Reply With Quote
Old 06-30-2017, 11:24 AM   #189
bFooz
Human being with feelings
 
Join Date: Jul 2010
Location: Slovakia
Posts: 2,588
Default

bumping this huge thing
bFooz is online now   Reply With Quote
Old 07-03-2017, 06:52 AM   #190
airon
Human being with feelings
 
airon's Avatar
 
Join Date: Aug 2006
Location: Berlin
Posts: 11,817
Default

Quite a bit of this could actually be done in Lua, using GUI libraries by fellow users.

It would be a lot of work, and I can't spend the time right now. Cockos is likely busy with other stuff as well.

Months ago I created a stack of images for that very purpose.


The time was not there to make this script. Maybe one day someone will do their own and share, or I'll manage to find a day to make it.
__________________
Using Latch Preview (Video) - Faderport 16 setup for CSI 1.1 , CSI 3.10
Website
"My ego comes pre-shrunk" - Randy Thom
airon is offline   Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -7. The time now is 02:16 AM.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.