From: Geoff B. <ge...@la...> - 2011-11-26 08:28:25
|
these really need work boys. we need decent, meaningful editors in the piano roll for midi. the sustain pedal is still not right, and trying to make sense of the yellow and white boxes is just beyond me.i think the white boxes are events and the yellow means .. well i dunno.. dead space or something ?? these have to mean something and be easily editable. show an event with an editable integer, that's what is required in all editors. velocity works well, but it's the only one. volume, program change, sus pedal - they're truly useless. they would be much better displayed as velocity is. that works. is that possible simply/easily? just choose different colours for the different events even and layer them in one controller pane perhaps? at least this is surely a graphical problem not a really technical one - so what can be done? best g |
From: Geoff B. <ge...@la...> - 2011-11-26 08:32:28
|
looking again it seems that sustain on events are not being tranmitted from bar1/beat; that is, i have a piano part with a sustain 'on' event at beat2/bar1 and no sustain is happening on playback until a later sustain 'up' event. g |
From: Geoff B. <ge...@la...> - 2011-11-26 08:36:26
|
On 11/26/2011 07:32 PM, Geoff Beasley wrote: > looking again it seems that sustain on events are not being tranmitted > from bar1/beat; that is, i have a piano part with a sustain 'on' event > at beat2/bar1 and no sustain is happening on playback > until a later sustain 'up' event. > > yeah, it seems the 'cure' is to add an up after the initial down pedal then down again. that works. so, down/up/down the it works as expected. g |
From: Florian J. <flo...@we...> - 2011-11-26 13:45:37
|
Am 26.11.2011 09:28, schrieb Geoff Beasley: > these really need work boys. we need decent, meaningful editors in the > piano roll for midi. the sustain pedal is still not right, and trying to > make sense of the yellow and white boxes is just beyond me.i think the > white boxes are events and the yellow means .. well i dunno.. dead space > or something ?? these have to mean something and be easily editable. > > show an event with an editable integer, that's what is required in all > editors. velocity works well, but it's the only one. volume, program > change, sus pedal - they're truly useless. they would be much better > displayed as velocity is. that works. is that possible simply/easily? > just choose different colours for the different events even and layer > them in one controller pane perhaps? > what do you mean? do you mean these controller canvases below the pianoroll canvas? i think, especially for volume and such stuff, they are really good. for sustain, they are a bit overkill, but usable, aren't they? which yellow and white boxes do you mean? showing controller events only as editable integers really sucks if you want to draw volume or panning curves. i think i don't quite understand your problem. can you please be more precise or maybe even make some kind of mockup how you'd like it to be? for your sustain problem: i can either not understand or not reproduce your sustain problem. could you please explain it better or create a test file? greetings flo > at least this is surely a graphical problem not a really technical one - > so what can be done? > > best > > g > > ------------------------------------------------------------------------------ > All the data continuously generated in your IT infrastructure > contains a definitive record of customers, application performance, > security threats, fraudulent activity, and more. Splunk takes this > data and makes sense of it. IT sense. And common sense. > http://p.sf.net/sfu/splunk-novd2d > _______________________________________________ > Lmuse-developer mailing list > Lmu...@li... > https://lists.sourceforge.net/lists/listinfo/lmuse-developer > > |
From: Geoff B. <ge...@la...> - 2011-11-26 21:03:41
|
On 11/27/2011 12:45 AM, Florian Jung wrote: > for your sustain problem: i can either not understand or not reproduce > your sustain problem. could you please explain it better or create a > test file? looking again it seems that sustain on events are not being tranmitted from bar1/beat1 that is, i have a piano part with a sustain 'on' event at beat2/bar1 and no sustain is happening on playback until a later sustain 'up' event. g |
From: Geoff B. <ge...@la...> - 2011-11-26 21:14:32
|
On 11/27/2011 12:45 AM, Florian Jung wrote: > what do you mean? do you mean these controller canvases below the > pianoroll canvas? i think, especially for volume and such stuff, they > are really good. > for sustain, they are a bit overkill, but usable, aren't they? yes, i mean those. what other editors are there? you are right, volume/mod wheel/velocity is great. program change is useless and ctl_#64 is just confusing. sustain is a simple on/off series of events. the problem is the 'time base' or duration of the event is drawn and that seems unnecessary to me. i suggest the way velocity is drawn would be more appropriate for sustain controller events. we need to know when the pedal is depressed and when it is pressed again. or perhaps show them as a single event (rectangle) with an editable start and end toggle that can be manipulated - instead of the current individual start and end events drawn separately. i also think that controller data should be erased every time you record - like in replace mode - if you're using mod wheel for example, overdubbing is problematic if existing events are there as well. 2c g |
From: Tim E. R. <ter...@ro...> - 2011-11-27 00:28:04
|
On November 27, 2011 8:14:18 AM Geoff Beasley wrote: > On 11/27/2011 12:45 AM, Florian Jung wrote: > > what do you mean? do you mean these controller canvases below the > > pianoroll canvas? i think, especially for volume and such stuff, they > > are really good. > > for sustain, they are a bit overkill, but usable, aren't they? > > yes, i mean those. what other editors are there? > > you are right, volume/mod wheel/velocity is great. program change is > useless IIRC I added program controller graph at someone's request. At least it allowed one to er, roughly see if there was anything happening. It kinda works, if you keep to a small controller7 domain. Anyway I propose, as you do below, that program graph become special like velocity is special. That it finally 'grow up'. Instead of a graph we print the names of the patches. With thin marker-like lines showing where the event happens. What if there are several program changes in a short time (or low zoom) with long names? Let's maximize all that available vertical space in the graph window, by 'staggering' and 'stacking' the text vertically, only if it would otherwise cause overlap with a neighboring name. Sure it's gonna look funny at low zoom, but hey, at least in theory you should be able to see all the patch names laid out vertically at low zoom. Hm, could it work? ... > and ctl_#64 is just confusing. That's sustain, right? > > sustain is a simple on/off series of events. the problem is the 'time > base' or duration of the event is drawn and that seems unnecessary to > me. i suggest the way velocity is drawn would be more appropriate for > sustain controller events. we need to know when the pedal is depressed > and when it is pressed again. > > or perhaps show them as a single event (rectangle) with an editable > start and end toggle that can be manipulated - instead of the current > individual start and end events drawn separately. Agreed. With midi controllers, there is no distinction between Boolean (on/off) stepped (3, 5, 7, 9...) and continuous controllers. They are all just Continuous Controllers (CC) from 0 to 127 (or more). But if you look at the latest audio automation graph behavior, you see I've added those distinctions so the line 'snaps' to the available audio controller values. (Note to Robert: It's drawing outside the track now. Is it me or the DB stuff?) So to get that same functionality out of the midi controllers, we would have to modify our class MidiController. This would add a few parameters in our Midi Instrument Editor where you could say "this controller is boolean, this one continuous..." But ask yourself what about more complicated controllers, ones which might have specific sequence of legal values. Unlikely, but you never know. It would make our Instrument Editor more complicated. Anyway these controller changes are something I'm working on for a while. Involves all that stuff we said about editing controllers, and my new branch. Sure not here in 2, but hopefully after. Stuck with it for now. However, the Program is something we might be able to take care of sooner. Program is a special MusE controller not like the others, easily distinguished from the others, so I think we can get away with modifying its canvas drawing. > > i also think that controller data should be erased every time you record > - like in replace mode - if you're using mod wheel for example, > overdubbing is problematic if existing events are there as well. Yes, I've seen that. I crossed coding paths with that issue a few times. The data becomes AFU from the overlaps. Was not time to do anything about it yet. But it is definitely bad. Should be marked as bug somehow. Need to do it. Tim. > > 2c > > g > |
From: Tim E. R. <ter...@ro...> - 2011-11-27 00:41:09
|
On November 26, 2011 7:27:42 PM Tim E. Real wrote: > On November 27, 2011 8:14:18 AM Geoff Beasley wrote: > > On 11/27/2011 12:45 AM, Florian Jung wrote: > > > what do you mean? do you mean these controller canvases below the > > > pianoroll canvas? i think, especially for volume and such stuff, > > > they > > > are really good. > > > for sustain, they are a bit overkill, but usable, aren't they? > > > > yes, i mean those. what other editors are there? > > > > you are right, volume/mod wheel/velocity is great. program change is > > > > useless > > IIRC I added program controller graph at someone's request. > At least it allowed one to er, roughly see if there was anything happening. > It kinda works, if you keep to a small controller7 domain. > > Anyway I propose, as you do below, that program graph become special > like velocity is special. That it finally 'grow up'. > Instead of a graph we print the names of the patches. > With thin marker-like lines showing where the event happens. > > What if there are several program changes in a short time (or low zoom) > with long names? > Let's maximize all that available vertical space in the graph window, > by 'staggering' and 'stacking' the text vertically, only if it would > otherwise cause overlap with a neighboring name. Actually editable and non-editable text overlays are one of the features of my branch. Remember I talked about canvas item 'drawing layers'? My branch's got 'em. I need to merge from 2.0, and then review. I've been thinking we should at least get that drawing stuff in the tree. I think that's pretty much all I did so far in there. Tim. > > Sure it's gonna look funny at low zoom, but hey, at least in theory you > should be able to see all the patch names laid out vertically at low zoom. > > Hm, could it work? ... > > > and ctl_#64 is just confusing. > > That's sustain, right? > > > sustain is a simple on/off series of events. the problem is the 'time > > base' or duration of the event is drawn and that seems unnecessary to > > me. i suggest the way velocity is drawn would be more appropriate for > > sustain controller events. we need to know when the pedal is depressed > > and when it is pressed again. > > > > or perhaps show them as a single event (rectangle) with an editable > > > > start and end toggle that can be manipulated - instead of the current > > individual start and end events drawn separately. > > Agreed. With midi controllers, there is no distinction between Boolean > (on/off) stepped (3, 5, 7, 9...) and continuous controllers. They are all > just Continuous Controllers (CC) from 0 to 127 (or more). > But if you look at the latest audio automation graph behavior, you see I've > added those distinctions so the line 'snaps' to the available audio > controller values. > (Note to Robert: It's drawing outside the track now. Is it me or the DB > stuff?) > > So to get that same functionality out of the midi controllers, we would have > to modify our class MidiController. > This would add a few parameters in our Midi Instrument Editor where you > could say "this controller is boolean, this one continuous..." > > But ask yourself what about more complicated controllers, ones which might > have specific sequence of legal values. Unlikely, but you never know. > It would make our Instrument Editor more complicated. > > Anyway these controller changes are something I'm working on for a while. > Involves all that stuff we said about editing controllers, and my new > branch. Sure not here in 2, but hopefully after. Stuck with it for now. > > However, the Program is something we might be able to take care of sooner. > Program is a special MusE controller not like the others, easily > distinguished from the others, so I think we can get away with modifying > its canvas drawing. > > > i also think that controller data should be erased every time you record > > - like in replace mode - if you're using mod wheel for example, > > overdubbing is problematic if existing events are there as well. > > Yes, I've seen that. I crossed coding paths with that issue a few times. > The data becomes AFU from the overlaps. > Was not time to do anything about it yet. But it is definitely bad. > Should be marked as bug somehow. Need to do it. > > Tim. > > > 2c > > > > g > |
From: Geoff B. <ge...@la...> - 2011-11-27 02:06:03
|
On 11/27/2011 11:40 AM, Tim E. Real wrote: > I need to merge from 2.0, and then review. > I've been thinking we should at least get that drawing stuff in the tree. > I think that's pretty much all I did so far in there. sounds very good to me ;) g |
From: Florian J. <flo...@we...> - 2011-11-27 13:42:54
|
sounds good. so we know what to do before 2.1 ;) greetings flo |
From: Geoff B. <ge...@la...> - 2011-11-27 02:05:24
|
On 11/27/2011 11:27 AM, Tim E. Real wrote: > Anyway I propose, as you do below, that program graph become special > like velocity is special. That it finally 'grow up'. > Instead of a graph we print the names of the patches. > With thin marker-like lines showing where the event happens. absolutely good idea. names actually don't bother me - it's the number that's important imo. you know you want to go from 23 to 76... for me anyway best g |