Well, the subject pretty much states the question: Why can't a plugin be bypassed via PCEs? What are your thoughts on the topic? Sometimes it might be useful to bypass a plugin for a small section, whereas normally the plugin it is on.. for example. Currently I believe one would have to modify the dry/wet ratio (if that's even possible with anything other than Zxx/SFx macros.. if even there..) inside the pattern data to do this.
Think of it like a distorion pedal on guitar. You have a non-distorted verse structure but really wanna 'blow it out' during the chorus.. so you step on the pedal to engage it when the time's right. Should be able to do that in the tracker! (someone correct me if I've missed it, but it seems to be missing this feature).
Why would you assume its not possible?
I assume with PCE you mean midi macros?
Assign a macro to the dry/wet slider, and set it to 0 to get your plugin bypassed.
Quote from: christofori on June 19, 2011, 07:24:45Why can't a plugin be bypassed via PCEs?
Because, as the name should suggest, they are
Parameter Control Notes. They can
only automate parameters. But yes, using a dry/wet Zxx macro might be what you want. It does not bypass the effect in the sense of stopping it, but at least it becomes inaudible (so it does what you want but it will probably not save you some CPU time etc)
Quote from: LPChip on June 19, 2011, 11:50:01
Why would you assume its not possible?
I don't -- I stated that I believed it WAS indeed possible in just the way you suggested... but as I had not yet ever done so and was relying only on memory I wanted to be clear that I wasn't SURE.
Quote from: LPChip on June 19, 2011, 11:50:01
I assume with PCE you mean midi macros?
No; PCE is common (I thought..) shorthand for Parameter Control Event; PC and/or PCS "notes" usable only in the .MPTM file format; sorry for not being more clear! ;)
Quote from: LPChip on June 19, 2011, 11:50:01
Assign a macro to the dry/wet slider, and set it to 0 to get your plugin bypassed.
Yep, this is how I thought it would be possible... but guys the problem I have with this method is that there are only 16 macros..! If you're like me (thank God there's only one me, but seriously..!) in that you use VSTi's (or their stand-alone equivilents as in my case... when PCEs are NOT AN OPTION...) that DO NOT show their parameters and/or allow one to assign or control ANYTHING VIA PCE (I have tried automation controls inside even the VSTi version of each player to no avail), you would want to keep as many MIDI MACROS free as possible. I use more than 8-10 in each track currently, most for ARIA (Garritan) and some others for various PLAY controls... but if I were to need to use many more you can see I'd run out quite quickly. Fortunately a few of the CC controls actually overlap in my case, meaning I can use the same SFx control (albeit with differing results..) seperately for each player's instrument(s).... but alas, I digress.
| [EDIT: Let's not even consider how setting a macro to "control plugin parameter" will actually control MULTIPLE plugins at the same time, no matter which instrument number is supplied via the macro pattern data..! I know this is by design; but it further limits the use of MIDI macros if one were to consider them to control VST plugins at all. Fortunately this is negated if one chooses to use PCEs via .MPTM modules, anyway...] |
Quote from: Jojo on June 19, 2011, 12:34:56
Quote from: christofori on June 19, 2011, 07:24:45Why can't a plugin be bypassed via PCEs?
Because, as the name should suggest, they are Parameter Control Notes. They can only automate parameters. But yes, using a dry/wet Zxx macro might be what you want. It does not bypass the effect in the sense of stopping it, but at least it becomes inaudible (so it does what you want but it will probably not save you some CPU time etc)
After reading the above response to LPChip, I'm hoping you can see the nature of my request a bit more clearly....
Besides, if one were to look at a VST like an effects pedal, whether the thing is engaged or not sure seems like a
parameter to me (my hardware pedals both have a bypass switch on them... which of course enables/disables their OUTPUT but not their power state -- so speaking virtually towards the VST, a bypass switch option shouldn't at all change CPU
utilization but only whether the signal(s) routed to said VST are
changed by the VST... as a pedal's bypass switch doesn't change the power used by said pedal...); ableit we may merely be parsing terminology now. It might not be a "true" parameter considering it's boolean; or considering it to be more of a host parameter than a VST parameter.. if the latter "floats your boat" better, then perhaps a HCE (Host Control Event) could be added into consideration, so as to avoid 'muddying' things more than needed..?
Again, as I use some libraries which allow ONLY MIDI CC#'s for automation (nothing else works... believe me when I say I've tried.. know you not that I tend to be thorough..?) in addition to other VSTi's which (thankfully!) DO respond to PCEs, it would be nice to avoid using MIDI CC macros for 'global' PARAMETERS like this. In my specific case, I had wanted to use something like a PCE to change the bypass boolean of a VST effect in the tracker; thus I realize of course (and admit freely) that I wouldn't be able to bypass either standalone library I use with the method... but that's not the point. The point is: why use a MIDI CC control for a VST??
Sure, not everyone fits the uniqueness of my particular case (how many people CANNOT use their sample libraries in VSTi form and must use VST2MID just to get them to work? I realize you could probably count them on one hand..) so I realize it likely won't happen... but then I think back to nobuyuki's original request/post: http://forum.openmpt.org/index.php?topic=4075.msg35945#msg35945 (http://forum.openmpt.org/index.php?topic=4075.msg35945#msg35945)
People are out there... and if someone's music were to become so known as to actually draw attention to OMPT, more people might begin to flock towards it (possibly away from ProTools or other "real" DAW solutions...) and then (possibly) be similarly disappointed because they might not be able to control that one extra thing they needed in some external library, because they had to assign a dry/wet MIDI macro in it's place... for a VST effect...! Shouldn't necesarilly even be referenced via MIDI CCs!...
[EDIT: Or perhaps solve all the problems by instead introducing a "MIDI Control Event" feature... let's face it, the "OMPT has poor MIDI support" line's just an excuse at this point, isn't it? I mean there are 127 MIDI CC#'s (arguably 128..) and they should not be viewed at all to be interchangeable with VST(i) parameters; as plugins like VST2MID open a world of possibilities to those like myself, and make the 'poor MIDI support' stance moot. Why then be limited to only being allowed to touch up to 16 of those 127/128 CCs? Remove the confusion by making MIDI macros obsolete -- introduce a suitable replacement feature, and the "potential" (or perhaps "looming" is the better word choice in my own case...) problem of one day running out of controls is thus eliminated.]
|
Which now that I look back, nobuyuki's post wasn't ever taken seriously, either. No response but my own.. and a negligeable number of reads, at that.
[sigh]
If you run out of macros, you can instead use the Z80-ZFF section for switching between 100% dry and 100% wet - The "off" macro would be F0F00300 and the "on" macro would be F0F0037F.
.. Well, that does indeed address the original question/request.. ;)
Forgive the ignorance in this question.. but is it really that difficult/time consuming to implement a control for midi CCs similar to the usability of a PCE, so that all 128 CCs could be controlled? You're already technically allowing people to assign control of a CC anyway, so the code should be in place.. (If my coding skillz weren't so archeic I'd take a crack at it.. I know you're overwhelmed and don't mean to pile onto you by any means..! I'm just imagining a sunny day sometime in the future, where all the feature requests and bugfixes are done/fixed, and you begin to wonder what's next... and then you think back and remember "Oh, chris and that other guy wanted CC controllers, and I've nothing better to do now that OMPT is perfect, so I'll add it!" -- it's that small a ray of hope for me..)
Argumentatively I am only asking because I am working under the assumption that libraries like Garritan will continue to add features over time, thus those control features will take yet another MIDI CC -- and there will (soon..) become a time when I will exceed 16 macros and become unable to continue working in OMPT. I suppose that 'ray of hope' I'm trying to hold onto will hopefully occur around that time (except that it contradicts with the word 'soon' I just used.. but eh, I can dream..!) I also don't want to get to the point of having to run a bunch of mixdowns, reprogram custom macro code for different instruments, and all that. Call me crazy but I like the functionality of pressing "play" in the tracker and everything playing as it's supposed to.. but if you're telling me "there is no hope and we will not implement CC controls ever" then I might as well begin hunting for my new DAW solution. :(
[EDIT: I believe I am caught up to the 'page' you're on when you're speaking of global parameter control -- the tree view actually clarified it for me. In it (for MPTM of course) one has: sequences, Patterns, Samples, Instruments, comments, and Plugins. This helped me realize that the end-goal of MPTM appears to be heading towards templates/projects (as sequences implies multiple songs using the same samples/instruments/plugins, whatnot). This I think I follow properly; however channel muting is global already if this scope of understanding I'm at is in line with your thoughts -- mute a channel in one sequence and it is then muted for all others as well.. Guess I still don't see what the 'big deal' is. Sure, let's say you play a sequence that DOES have a setting to turn a plugin's bypass ON (bypassing it) and then you go play another sequence. That 'you' in this example CANNOT claim fault on OMPT for the plugin being bypassed when they play another sequence (that didn't know any better..) as their bypass switch needed to have been reinitialized (and/or unset if you will..) at the end of their first sequence. I dunno.. I guess it doesn't really matter whether I understand what you're talking about or not as I've got only one option (which involves disabling another control I may/may not want to use for samples/VSTs anyway) -- so either way you slice it I'm left with a work-around as a solution...
As it stands, I'm already calling PC events to specifically set values of a VST before the VST is even used in the song, in case another sequence may happen to modify the VST parameter(s) before I have a preset saved as a 'just in case' -- is the implication that adding a bypass control switch via PCE = it'll mess up another sequence? Hope not... that theory's got holes all thru it already.. :)]
|
Quote from: christofori on June 20, 2011, 14:40:53
but is it really that difficult/time consuming to implement a control for midi CCs similar to the usability of a PCE, so that all 128 CCs could be controlled?
Probably. I don't really have the time for that at the moment, though.
I really do wish I had VS and the updated knowledge/skillset to help out. I don't know squat about audio programming; just a basic (and dated..) knowledge of C/C++ commands and structure.. didn't get into visual. Used gcc if I recall.. but that's not helpful I wouldn't guess, kinda need VS2003 at least as I understand. :( If I can swing getting it over time, I might be able to help out with the small stuff though.. perhaps one day..! >:D
There's a goal for you! (well it's my goal.. well you know what I mean..)
I think getting VS would be the very smallest issue when wanting to write code for MPT...
From the (few) references I've caught in forum discussion relating to it's code, I can already state you're absolutely right.
However, my brain's not wired the same as most (oh, THAT's his problem then..! lol)... and though it might not at all transpire this way, I still like to think I'd somehow be able to relate to the code in a way as to follow it more easilly than someone with more 'proper' and structured code practices could. Don't forget that the bulk of my 'experience' was self-taught and learn-as-you-go beginning with basic and pascal (similar to Mr. Lapicque beginnings if I'm not mistaken); so what today's programmers consider nonsensical and even 'bad practice' I'd be more accustomed to. I just wish I didn't have the gap in experience that I do.. been since 2002 that I've coded anything in C/++ though I still have some books somewhere... Perhaps I'll work towards this goal after all, you never know. I know it'd be uber-nice to have someone come along and reorganize the code structure to modernize it for you.. ;) Can't promise anything but as time rolls along I'll dive in and see what I can break along the way.. :P Besides, doing so may be my only avenue to realize MCEs that I so badly desire.. :)
I guess the starting point is to download the code and read trough it. Visual studio can be downloaded used for 90 days.
After these 2 songs I'm working on are done.. ;)
I wouldn't say that the code is similar to something that someone who has used BASIC (like me) or Pascal for a long time might be accustomed to or could have written. On the contrary, it's just full to the brim with pointers, macros and old-fashioned code structures, and the latter is what has spawned many redundant pieces of code, or simply code that runs fast but is hard to understand (*). We have tried to make the code look better in the last years (while still being fast), but there is still a lot of work to be done, really.
(*) Here's a nice riddle for you: What does the following code do (m is a pattern cell)?
if ((!*((LPDWORD)m)) && (!*(((LPWORD)m)+2)))
Certainly not BASIC style, eh :D
Quote from: Jojo on June 21, 2011, 16:09:30
(*) Here's a nice riddle for you: What does the following code do (m is a pattern cell)?
if ((!*((LPDWORD)m)) && (!*(((LPWORD)m)+2)))
Oh this is easy!
The looped word of the patterncell has to be the same as the looped word of the pattern cell +2.... Or something... :nuts:
Hmm let's see...
[ ] Understood basic WinAPI data types and naming conventions
[ ] Understood the meaning of &&
[x] Silly post! :P
Quote from: Jojo on June 21, 2011, 16:09:30
I wouldn't say that the code is similar to something that someone who has used BASIC (like me) or Pascal for a long time might be accustomed to or could have written. On the contrary, it's just full to the brim with pointers, macros and old-fashioned code structures, and the latter is what has spawned many redundant pieces of code, or simply code that runs fast but is hard to understand.
Old-fashioned code structures... The structure is exactly what I was talking about.. or moreover, the lack of "readable" structure that existed a while ago, before they wanted to put forth effort to train programmers to make code more readable, anyway.
I'm not thinking I'll be able to come in and clean up the code, now.. lol.. your example was time well spent. But I might still play with it and customize it somewhat. ;) Only problem in doing that is if I did come up with a good bit of code I ended up using (dare I say relying upon..?), I'd have to then re-implement it each time a new build came out (or submit it to you for inclusion I suppose, do you ever incorporate user-submitted code bits [FE features]?)
Quote from: christofori on June 22, 2011, 01:00:25
ers to make code more readable, anyway.
Let me tell you one thing, many parts of the code
are unreadable if you don't spend some time figuring out what they do. :D And once you've understood them, you can often easily replace them by something more readble (or maybe just add a comment on what the code does).
Quote from: christofori on June 22, 2011, 01:00:25
do you ever incorporate user-submitted code bits [FE features]?
No, because there aren't any. :D Well, the last patch from outside the development team was from kode54 I think, and I gladly incorporated his fixes - everyone is welcome to make changes to the code and send them to us!
Noted for (possible) future development... 8)
Are you sure, I know Pelya made a vsti version of modplug and he also did sync with video thingy. I dont think that that has been incorporated in todays build.
Uhm, so what? The VSTi patch was experimental and a dirty hack - and AFAIK pelya didn't submit it as an official patch (I wouldn't have done that, either). Some of his other patches have made it into codebase, though.
An idea that'll probably never be implemented as most don't use this setup (yet... I believe it will become more common than it is today..) -- support for multiple monitors for OMPT content (I know you can move VST(i)'s... I'm talking about sample/instrument/pattern/general tidbits -- being able to see it all, baby!)... but after having read some about the GUI in various snippits from past dev conversations (maybe some from the issue tracker.. hard to remember where I found 'em now..), I know... I know. I can dream..! :D
But, this all goes to reinforce why I've quit submitting issue tickets without checking around a lot more, first.. and then even posting here for debate first. Because of course, what I might think of as a 'must-have' most others might care less for..! :P At any rate, I figured there was no need to add clutter to the IT.
Try Window -> New Window. I think this is what you want.
Quote from: Jojo on June 21, 2011, 16:09:30
(*) Here's a nice riddle for you: What does the following code do (m is a pattern cell)?
if ((!*((LPDWORD)m)) && (!*(((LPWORD)m)+2)))
Well, i understand the syntax, the vocabulary, but i often have trouble interpreting what it's trying to do...
Let's see...
Take the value of m as a DWORD pointer (in its DWORD-length memory location) and compare the bits (AND) with the value of m's WORD-length pointer plus 2, if they're the same...
Is that close? I forget what the exclamation point is for (if i know at all), and that may have a drastic effect on the interpretation...
That statement is exactly why i didn't what to mess with the code, i barely have a clue what's going on from one line to the next. I started creating a REM-happy version of the code with each line put in plain English, but i kept getting stuck on lines like that one.
I'm secretly hoping that one day before the code gets too obsolete, you'll refactor everything into something so clear i can actually do something with it...
You've gotten pretty close actually! The && is not a logical AND, though, so the two statements are not compared or anything - the code is only executed if both are true.
Let's take a closer look...
(LPDWORD)m - Reinterpret the mod command pointer as a DWORD (32-bit integer) pointer
*(LPDWORD)m - Dereference the pointer, i.e. look at the DWORD value at the given address
!*((LPDWORD)m - Check if that DWORD value is 0
(LPWORD)m - Reinterpret the mod command pointer as a WORD (16-bit integer) pointer
((LPWORD)m)+2 - Skip two WORDs (i.e. 4 bytes)
*(((LPWORD)m)+2) - Dereference the pointer, i.e. look at the WORD value at the given address
!*(((LPWORD)m)+2) - Check if that WORD value is 0
In other words, this code check if 6 consecutive bytes (that's the size of a pattern cell) at address m are zero. After refactoring, it looks like this:
if(m->Empty())
;D
That's right! The exclamation point is the NOT operator!
Your final code is what is needed throughout. It's so elegant! ;)
BTW: Is/was that snippet really present in the code? Why do you figure it was originally written in longhand like that? Any guesses?
Quote from: Harbinger on June 23, 2011, 15:03:54
Is/was that snippet really present in the code?
Yes (http://modplug.svn.sourceforge.net/viewvc/modplug/trunk/OpenMPT/mptrack/Draw_pat.cpp?revision=870&view=markup&pathrev=870#l864).
And why it was used? I'm sure Olivier wanted to be efficient (this is probably even faster than a memcmp() call), and he was the only person working on the code, so if he understood it, it was fine. Remember that most of the old code was not strictly object-oriented, so object functions like MODCOMMAND::Empty() didn't even exist in the old code.
Quote from: Jojo on June 23, 2011, 14:05:12
if(m->Empty())
Now that part I understand. It questions itself and then makes M empty! Yeah, that must be it. :nuts:
Quote from: Jojo on June 23, 2011, 11:19:20
Try Window -> New Window. I think this is what you want.
Sorta; although you cannot move any of the windows outside of the main OpenMPT application window (which was the goal of the comment, being that multiple monitors were mentioned) and onto another physical screen. Part of the functionality is there already as you point out, since one is able to split the existing display and arrange the parts as desired; but this assumes one has a rather large monitor (well, someone with a LCDTV as one perhaps would work..) to be able to see portions that were useful... if you can't see but a fraction as your screen is too small however, it doesn't do any good.
Actually, this brings up an interesting question, since you're working with more than one monitor...
Are you able to stretch ModPlug's window over into more than one monitor? This could definitely expand MultiView's functionality (multiple windows of the same track)...and i'd like to mention the possibilities in the OHM...
Quote from: Harbinger on June 27, 2011, 20:33:38
Actually, this brings up an interesting question, since you're working with more than one monitor...
Are you able to stretch ModPlug's window over into more than one monitor? This could definitely expand MultiView's functionality (multiple windows of the same track)...and i'd like to mention the possibilities in the OHM...
Its windows. Any window that you can resize, can be moved to several monitors at the same time, so yes.
There are programs and drivers that allow you to create one huge desktop made out of more displays. If you have this kind of setup, maximize will actually put the screen on both windows automatically.
Actually I'm not sure if you can maximize the Window over several screens, but in windowed mode it's no problem to extend the window to multiple screens. Though I generally prefer to just put plugin editors on a secondary screen, which doesn't need the main window to be extended.
Quote from: Jojo on June 28, 2011, 16:24:45
Actually I'm not sure if you can maximize the Window over several screens
By default, no. But either by some software that add it as a context menu option or special command, or by drivers who will create one desktop over several screens, you can. Of course, there are some limitations, like both desktops must have the same desktop size.
Quote from: LPChip on June 28, 2011, 17:00:18
By default, no. But either by some software that add it as a context menu option or special command, or by drivers who will create one desktop over several screens, you can. Of course, there are some limitations, like both desktops must have the same desktop size.
Correct; NVidia's NView desktop manager software being one which allows this type of feature, and additionally sets another "Maximize All" button for your windows (up where the standard minimize, restore/maximize, and close "X" buttons are on the title bar). I however am just using Windows' default support of multiple monitors with no added functionality; so indeed as Jojo suggests, maximizing a window does so on the active monitor (whichever one the application is mostly on at the time the max command was issued).
http://www.christofori.net/images/christofori-tracker_on_multi-monitors.jpg
You will see that I've arraged my screens in a kind of L-shape; the main monitor (notably where the taskbar is) is the largest of the three, while the other 2 in a vertical configuration are much smaller (you can see the bottom of which by the forum open behind the tracker window). :)
Quote from: Jojo on June 28, 2011, 16:24:45
Though I generally prefer to just put plugin editors on a secondary screen, which doesn't need the main window to be extended.
Me too. Didn't have any open at the time of the screenshot; though you can see one of my PLAY windows behind the tracker on the main screen... I just think it'd be cool to be able to modify instruments AND watch pattern data go by, but it might just be me...
Also it should be noted that depending on the hardware involved for the screens, one will get different performance results in the tracker when it runs restored (stretched, not maximized) across multiple screens -- as for me, and my example; I've got an older Intel dual card running my smaller screens, and when stretching the window over to them there were some pops in the audio.. they didn't last though, until moving it back. My PCI bus probably wondered what the heck I was doing for a moment, though.. :)
Quote from: christofori on June 29, 2011, 14:36:46
I just think it'd be cool to be able to modify instruments AND watch pattern data go by, but it might just be me...
You can do that by creating a new window. (menu window-> new window) and drag it to the other screen. Select whatever tab you want to view over there and you're set!
Quote from: LPChip on June 29, 2011, 14:48:27
You can do that by creating a new window. (menu window-> new window) and drag it to the other screen. Select whatever tab you want to view over there and you're set!
... IF the tracker's already spanning all of your screens, then yes, you are correct.
Tracker windows must exist inside the main OMPT tracker window interface.
Quote from: christofori on June 29, 2011, 14:50:12
Quote from: LPChip on June 29, 2011, 14:48:27
You can do that by creating a new window. (menu window-> new window) and drag it to the other screen. Select whatever tab you want to view over there and you're set!
Tracker windows must exist inside the main OMPT tracker window interface.
Ah... yeah, thats true. Didn't think of that.
... IF the tracker's already spanning all of your screens, then yes, you are correct.
Quote from: christofori on June 29, 2011, 14:50:12
Quote from: LPChip on June 29, 2011, 14:48:27
You can do that by creating a new window. (menu window-> new window) and drag it to the other screen. Select whatever tab you want to view over there and you're set!
... IF the tracker's already spanning all of your screens, then yes, you are correct.
Tracker windows must exist inside the main OMPT tracker window interface.
This is why i asked about using multiple monitors. I want to include a blurb in the next release of the OHM which expands MultiView with multiple monitors. Using more than one monitor can be as beneficial as activating more than one plugin with a single note. I do want to be sure, however, that stretching ModPlug's parent window over more than one screen canNOT be done natively with Windows -- one must have a video card and driver which allows it.
Christofori, if you can upload a screenshot which shows 2 displays showing how the parent window can be stretched, and different child windows of the same track (one for the General Tab and the other showing the Patterns page), i want to include it in the next help manual. But, and you're going to hate me for asking this, but i need the screenshot to show the original ModPlug theme (even though i love your Commodore 80 screen coloring scheme).
And one last question for multiple monitor users: If you reposition the dialogs (esp. the ones that can stay open while you work in Modplug's PE in the background) to the other screen (these do not rely on the parent window), do they always open in the main monitor or do they re-open in the last position you left them, on the other screen?
Quote from: Harbinger on June 29, 2011, 20:30:13
I do want to be sure, however, that stretching ModPlug's parent window over more than one screen canNOT be done natively with Windows -- one must have a video card and driver which allows it.
As said, in windowed mode you can stretch the window without any additional drivers, in maximized mode you can only achieve this by using the appropriate driver software.
QuoteChristofori, if you can upload a screenshot which shows 2 displays showing how the parent window can be stretched
I'm not sure how such a screenshot would help a lot with explaining how this works - afterall, you cannot determine what part of the windows is on which screen, right?
QuoteIf you reposition the dialogs (esp. the ones that can stay open while you work in Modplug's PE in the background) to the other screen (these do not rely on the parent window), do they always open in the main monitor or do they re-open in the last position you left them, on the other screen?
Depends on the dialogs, most of them are just set up to be centered, others (f.e. plugin screens) remember their position. No difference to single-monitor setups.
Why can't you make a screenshot that tells it all?
See attachment. :) (sorry for the crappy quality, but 256kb limit is... limited :P
That's not a screenshot, that's a photograph. :P
Quote from: LPChip on June 29, 2011, 21:10:18sorry for the crappy quality, but 256kb limit is... limited :P
Ever heard of picture uploading services? :>
Quote from: Jojo on June 29, 2011, 20:35:48
Quote from: Harbinger on June 29, 2011, 20:30:13
Christofori, if you can upload a screenshot which shows 2 displays showing how the parent window can be stretched
I'm not sure how such a screenshot would help a lot with explaining how this works - afterall, you cannot determine what part of the windows is on which screen, right?
One could so determine, were I to be nice and outline the monitor edges with a highlited color before uploading said screenshot(s). ;)
I can do this tonight -- but I've got a rehearsal to lead in an hour or so. Should have time after that and some evening chores. :)
Quote from: Harbinger on June 29, 2011, 20:30:13
But, and you're going to hate me for asking this, but i need the screenshot to show the original ModPlug theme (even though i love your Commodore 80 screen coloring scheme).
Nah; hate's an awefully strong word, anyway. Although the window/menu/etc. coloring being green has a lot more to do with my Windoze color scheme than my OMPT colors; though I might just set up a test user for this (and perhaps others of just this kind of thing) so I'll be able to show the defaults to reduce confusion... (and I'll see about a portable/defaulted OMPT for said test user as well, while I'm at it..). I could then do a few new windows and set them to different views in OMPT (say, instruments in one, patterns in another, and perhaps general or samples in the final) -- the only tricky part (considering my L-shaped layout) is going to be setting the pattern window to not be TOO BIG for my main screen (but of course it'll just be a sub-window, so it won't be tricky at all..) -- but just mentioning the added details so ya'll shall know I'm trying to not leave anything out.. ;) The test user of course is so I don't have to muck up my own profile for testing/demo purposes.. ;)
I could also do another set showing plugin controls on a screen as well, since it seems to be the popular way to use them amongst the crowd here.
I suppose, all this already IS/WAS possible in current/past builds; but in bringing it up at all, I was looking for the ability to move the 'sub windows' outside of the tracker's main window (or, switch perhaps to a mode with NO main window and only sub-windows... but that could be dangerous...) -- should've been a
tad more specific.. ^_^
[Edit: had an extra nested quote messing me up slightly.. lol..]
Quote from: christofori on June 29, 2011, 22:23:38I was looking for the ability to move the 'sub windows' outside of the tracker's main window
This is not possible with MDI (http://en.wikipedia.org/wiki/Multiple_document_interface) applications. You can only move dialogs and similar windows out the main workspace, but no child document windows.
Just need to show Modplug's window over 2 screens (upper/lower or side-by-side). Don't worry about the coloring scheme after all, unless it's easy for you to assemble. I'll just do a mockup based on your screenshot if necessary. And BTW, LPChip indeed shows the capability, but i need a straight 2D image, to show how you can use multiple monitors to separate the different child windows for one track.
And also -- no rush. I'm not rushing on my work, no since you rushing on this... 8)
Quote from: Jojo on June 29, 2011, 20:35:48
Depends on the dialogs, most of them are just set up to be centered, others (f.e. plugin screens) remember their position. No difference to single-monitor setups.
OK, so with 2 monitors, i can slide my plugin GUIs for example over to the second screen, without having to close them so i can see the Pattern Editor and use the GUI. That's the biggest selling point for multiple monitors yet. Perhaps i can make a FR to make some of these dialogs modal (modeless?) so they always stay open even when you're working in the PE. Off the top of my head: Find/Replace, Macro Manager, Channel Manager...orf course, some of these would need an Apply button to exceute the function but not close the window....
Quote from: Harbinger on June 29, 2011, 22:39:09
Just need to show Modplug's window over 2 screens (upper/lower or side-by-side)
As you will see below in the screenshots, my displays being different resolutions makes 2 screens more difficult perhaps... Or this could even show the possibilities of 3, making the number more popular indeed.. (Each person I've worked with that we enabled multiple monitor workstations for when I was in IT, always started out "I've got one, what would I use 2 for?" -- then they get the second one, and can't go back to 1... I've found the same 'love' of desktop 'real-estate' continues growing when one is used to 3 or 4 or more monitors as well..)
Quote from: Harbinger on June 29, 2011, 22:39:09
And also -- no rush. I'm not rushing on my work, no since you rushing on this... 8)
Perhaps a bit outside the norm; and I'm afraid I can't show you any different as I don't have 2 evenly matched resolution displays, but my funky 3 L-shape. Either way I think you might be able to use these images.. and they should be pretty self-explanatory. Each was a screenshot taken of all 3 'views' of the desktop taken simultaneously; note as I had to expand the main/parent OMPT window largely enough to fill all 3 in my current configuration, that the title bar's controls (maximize, X, etc) are NOT visible; also should be noted my display resolutions are:
#1 = 1280x960
#'s 2 and 3 are both 1024x768
http://www.christofori.net/images/MultiMonitorsAndWindows1.JPG (http://www.christofori.net/images/MultiMonitorsAndWindows1.JPG)
http://www.christofori.net/images/MultiMonitorsAndWindows2.JPG (http://www.christofori.net/images/MultiMonitorsAndWindows2.JPG)
I doubt I'll remove the pics for a while; but if you want to take copies and modify them for your purposes and/or include them in the OHM of course you're more than welcome to do so. ;) Probably best not to permanently link the OHM to pics on my site though, just in case I delete them while 'spring cleaning' or whatnot.. ;)
Quote from: Harbinger on June 29, 2011, 22:39:09
OK, so with 2 monitors, i can slide my plugin GUIs for example over to the second screen, without having to close them so i can see the Pattern Editor and use the GUI. That's the biggest selling point for multiple monitors yet.
IMHO Yep, at the moment. ;) Though, wacko's like your's truly here can do some other stuff that could come in handy at times.. Especially for those who want to keep tabs on multiple things at once (though I should state I've not tried editing multiple things on the fly in this setup as I don't run it often due to sound pops mentioned previously; but one with a nice new fast rig and good multi-display video cards [that don't hog the bus..] wouldn't have the same issues...)
[Edit: Note that even though I show the plugin windows inside the OMPT 'parent' window in ss #2 above, they actually are NOT; they are OVER the window; clicking on the parent window would bring it to the forground and cover the plugin GUI's in my case (I wasn't being as thorough as normal, perhaps.. heh..)]
Excellent pix! I will use the second one as it shows more functionality with extra windows like for the plugin GUIs. ;)
Thanks for your help, and you can expect to see this image (or one like it) in the next OHM! 8)
No problem. ;)
Had I known you'd use (one of) them (rather than looking/waiting for a more common 2-screen/side-by-side screenshot, for example) I'd have picked a niftier font for the monitor labeling.. :P