|
|
|
01-29-2013, 09:02 AM
|
#201
|
Human being with feelings
Join Date: Dec 2008
Posts: 2,111
|
I'm getting a reproducible crash when auditioning MIDI items in Project bay.
Steps to reproduce:
1. Create new project.
2. Insert one MIDI item.
3. Open the MIDI item to MIDI editor.
4. Add some notes to the item.
5. Open Project bay and select Media Items tab.
6. Click play button in front of the MIDI item.
-> Reaper CRASHES!
The crash does not happen if MIDI editor is closed before play button is clicked in Project Bay.
Tested on
Reaper v4.33pre2, 32bit
Windows 7 x64
jnif
|
|
|
01-29-2013, 09:10 AM
|
#202
|
Human being with feelings
Join Date: Aug 2011
Posts: 149
|
Quote:
Originally Posted by jnif
I'm getting a reproducible crash when auditioning MIDI items in Project bay.
|
Reproduced here on a Vista 32 system
|
|
|
01-29-2013, 10:19 AM
|
#203
|
Human being with feelings
Join Date: Aug 2012
Location: central Texas
Posts: 962
|
Quote:
Originally Posted by jnif
I'm getting a reproducible crash when auditioning MIDI items in Project bay.
|
Confirmed here. Reaper v4.33pre2 64-bit, Win7 x64
@gembez: No, you're fine. That was for gpunk.
|
|
|
01-29-2013, 11:25 AM
|
#204
|
Human being with feelings
Join Date: Oct 2007
Location: home is where the heart is
Posts: 12,110
|
Quote:
Originally Posted by gpunk_w
Oh wow, been waiting so many years for you to fix this, any chance you actually will ?
Still exactly the same as it always was.
Slice a MIDI item, glue it, open it, bam undocked
FAIL
|
Can't reproduce here, tried several times.
I have 'open all track MIDI in the last focused MIDI editor, preserve existing editor contents' enabled in Prefs/MIDI Editor. Maybe it's got something to do with that ?
Or maybe it's a Mac thing ? (you're on Mac from what I remember, aren't you ?)
|
|
|
01-29-2013, 12:03 PM
|
#205
|
Human being with feelings
Join Date: Mar 2007
Posts: 21,551
|
Quote:
Originally Posted by EvilDragon
It would also help, since we're dealing with MIDI now, that CCs are not reset on looping a time selection.
|
Should they chase in that case though?
Example: If you loop the range below, should it (when it goes back to the start) chase the previous last same CC from the previous clip, or reset to to that first CC before it hits, or should it remain on the last CC value in that clip until it hits the first event again?
----CC(value 40)---CC(value 75)---CC(value 120)---
|
|
|
01-29-2013, 12:19 PM
|
#206
|
Human being with feelings
Join Date: Jun 2009
Location: Croatia
Posts: 24,798
|
If you only have that clip selected, it should loop the CC back to 40.
If your time selection is wider, it should chase whatever the CC value is at the start of time selection. But it should not reset any CCs on its own volition.
|
|
|
01-29-2013, 02:01 PM
|
#207
|
-blänk-
Join Date: Jun 2008
Posts: 11,359
|
Not sure I agree (might be I misunderstand). I don't think length of the time selection has anything to do with it. Bottom line should be: wherever the loop is, it should sound the same as when just played linearly through the project.
If there is a previous CC event it should always chase back to that, as that would be how the area at loop start would sound when played linearly. If there is none it should reset to a reasonable value (the one you'd expect the default of the instrument to be).
|
|
|
01-29-2013, 02:19 PM
|
#208
|
Human being with feelings
Join Date: Jun 2009
Location: Croatia
Posts: 24,798
|
That was exactly what I said
|
|
|
01-29-2013, 02:34 PM
|
#209
|
Human being with feelings
Join Date: Mar 2007
Posts: 21,551
|
Interesting. I'll have to try that in Cubase to see what happens.
I think it'll probably do exactly what you guys are saying, chase back from the last previous CC event / value before the loop start, assuming there is one there to chase.
I always look at Cubase to get a feel for that kinda stuff since they seem to have gotten most of it right via years of trial and error I guess.
|
|
|
01-29-2013, 02:58 PM
|
#210
|
Human being with feelings
Join Date: Jan 2010
Location: Kalispell
Posts: 14,759
|
First of all I don't think an experienced midi programmer is going to leave an item, with a midi note(s), open ended with no current or prior CC value(s).
So it should always chase back for the latest.
However, if by accident there isn't any then it should retain the last played CC value. In Lawrence's little demonstration that would be 120.
----CC(value 40)---CC(value 75)---CC(value 120)---
Unless, Reaper can look ahead and see the value of 40?? (Can Reaper actually look ahead??) In that case it should be 40..
I also have to ask, are there any Reaper Defaults for this? Other than 0 or 127, neither of which is reasonable or usable in my estimation.
|
|
|
01-29-2013, 03:04 PM
|
#211
|
Human being with feelings
Join Date: Jun 2009
Location: Croatia
Posts: 24,798
|
It doesn't make sense to chase back to 120 if you're looping a time selection, and you have 40 at the start of the time selection.
|
|
|
01-29-2013, 03:10 PM
|
#212
|
Human being with feelings
Join Date: Jan 2010
Location: Kalispell
Posts: 14,759
|
Quote:
Originally Posted by EvilDragon
It doesn't make sense to chase back to 120 if you're looping a time selection, and you have 40 at the start of the time selection.
|
I'm not saying chase back to 120, I'm saying use 120 if there are no CCs to chase back to, it's better than 0 or 127.
And I'm assuming that 40 is not before or at the beginning of the first note in the loop so my question, can Reaper look/seek ahead to see it??
|
|
|
01-29-2013, 03:26 PM
|
#213
|
Human being with feelings
Join Date: Mar 2007
Posts: 21,551
|
Nobody would "program" that but if you split 40 midii tracks you might end up with stuff like that in some places, unless you did all you CC automation by hand on the grid and only ever split midi data the grid.
There's two kinds of midi production, locked to the grid (dance, rap, etc) and performances where people just play midi instruments and record them like audio, where thing actually don't (and often shouldn't) be tightly locked to the grid.
Reaper seems to have most issue editing the latter.
|
|
|
01-29-2013, 03:28 PM
|
#214
|
-blänk-
Join Date: Jun 2008
Posts: 11,359
|
Can we leave the term time selection out of this? It irritates me tbh. We are talking about a looped area, right?
If 40 is right at the start of the loop, there should be no problem, is there? If 40 is a bit in, and no previous CC exists, I am of the opinion that keeping the last value of the loop is not correct.
For most (not all) CC 127 is the value I expect to fall back to, as that's usually what an instrument has as default. If you change that in your instrument patch, you should put a set-up value at project start, IMO. And that should be fallen back to.
Obvious exceptions are pitch and pan, but also volume. The latter I'm not sure of. Some of my GM modules defaulted to value 100, if I remember correctly, but most VSTi I know of seem to be 127.
A much more diverse setup of when to reset which CC to which value would be good.
|
|
|
01-29-2013, 03:39 PM
|
#215
|
Human being with feelings
Join Date: Nov 2006
Posts: 2,533
|
Quote:
Originally Posted by gofer
If there is a previous CC event it should always chase back to that, as that would be how the area at loop start would sound when played linearly.
|
Exactly. You wouldn't expect an audio Media Item on loop to keep the value of the last few loop_end samples when it loops back to the loop_start.
Quote:
Originally Posted by gofer
If there is none it should reset to a reasonable value (the one you'd expect the default of the instrument to be).
|
Yep. A few examples:
- CC Mod value: 000
- Pitch should go to the center value (no pitch shifting up nor down)
- sustain pedal: off
There are more, of course, but these 3 are commonly used, so I just listen them.
|
|
|
01-29-2013, 03:41 PM
|
#216
|
Human being with feelings
Join Date: Aug 2012
Location: central Texas
Posts: 962
|
Quote:
Originally Posted by Tod
I'm not saying chase back to 120, I'm saying use 120 if there are no CCs to chase back to, it's better than 0 or 127.
And I'm assuming that 40 is not before or at the beginning of the first note in the loop so my question, can Reaper look/seek ahead to see it??
|
Yeah, the CC is undefined from time zero to before the first CC event. No CC event is sent when the playhead jumps into that area, so the MIDI destination's CC stays set wherever it happens to be. From the time of the first event to time infinity, the CC can be thought of as being continuously defined, so chasing should create the illusion of an envelope.
Last edited by medicine tactic; 01-29-2013 at 03:57 PM.
|
|
|
01-29-2013, 03:43 PM
|
#217
|
Human being with feelings
Join Date: Mar 2007
Posts: 21,551
|
Unrelated to loop chasing, the current design seems to assume unchanging linear arrangement. For example, if I place a CC event on a track, say a single CC volume event on a 2 minute long midi clip at 1.0.0 to set the volume, and then split that clip later and put something else in the middle of those two, the original split portion doesn't seem carry the original CC volume with it... it chases the new clips last CC level.
What would that be... chase to trimmed CC's or something?
Take something like Cubase with a single CC event at 1.0.0. Every clip split from there carries that value with it. If I split a part of that to another track it will still spit out the original CC value at each split's start... not even having the original event to chase.
Not sure if "lines" for CC's vs "bars" has anything to do with that, and/or maybe I'm just missing an option to make that stuff follow, dunno... but (for me, with the caveat that maybe I missed an option which is possible) it results in a bit of a mess when you start chopping things up.
Last edited by Lawrence; 01-29-2013 at 03:53 PM.
|
|
|
01-29-2013, 03:50 PM
|
#218
|
-blänk-
Join Date: Jun 2008
Posts: 11,359
|
Yeah, thinking about it, I really don't expect 127 for most, but actually 0. Except the exceptions Pitch, pan, volume, expression. Still not sure which I forget... just to mention some
It's a tough topic. GM folk will probably expect CC74 (cutoff Freq) to go to 127 (or100??), 91 (reverb/FX1) to something around maybe 30 and maybe some other specialties, while folks who use the CC more freely will like 0 more for these as well, or like Ted something completely different.
|
|
|
01-29-2013, 03:56 PM
|
#219
|
-blänk-
Join Date: Jun 2008
Posts: 11,359
|
Lawrence, Logic (the old PC version) didn't do that, and I am not entirely sure whether I really like it. At least I'd not expect it. Pretty sure there is an option to switch it of in Cubase, the creation of a leading-in CC event when splitting.
|
|
|
01-29-2013, 04:02 PM
|
#220
|
Human being with feelings
Join Date: Mar 2007
Posts: 21,551
|
So ... if you wrote a bunch of cc automation settings on a 16 bar midi clip, say using 4 different CC's, volume, pan, expression, whatever, and all those events or settings are in the first 8 bars of the clip, and later you decide to split that clip into two 8 bar clips and re-arrange them, you'd prefer to just lose all the CC automation settings on the split clip?
Not me personally, that would mean I'd have to repeat work that I've already done.
|
|
|
01-29-2013, 04:16 PM
|
#221
|
Human being with feelings
Join Date: Nov 2006
Posts: 2,533
|
Is this sensible?
|
|
|
01-29-2013, 04:29 PM
|
#222
|
Human being with feelings
Join Date: Aug 2012
Location: central Texas
Posts: 962
|
Quote:
Originally Posted by mikeroephonics
Is this sensible?
|
Well, for it to work it'd need to be more like an "initial value map" that could be saved and loaded on a per-track basis. In it you could define initial values for all 128 CCs of all 16 channels. It'd basically just eliminate the need for a MIDI media item at time 0 containing all the initial values. A global or project-wide setting is just too coarse.
Last edited by medicine tactic; 01-29-2013 at 04:35 PM.
|
|
|
01-29-2013, 04:32 PM
|
#223
|
-blänk-
Join Date: Jun 2008
Posts: 11,359
|
Quote:
Originally Posted by Lawrence
So ... if you wrote a bunch of cc automation settings on a 16 bar midi clip, say using 4 different CC's, volume, pan, expression, whatever, and all those events or settings are in the first 8 bars of the clip, and later you decide to split that clip into two 8 bar clips and re-arrange them, you'd prefer to just lose all the CC automation settings on the split clip?
Not me personally, that would mean I'd have to repeat work that I've already done.
|
I guess it depends. Normally I'd expect, when I rearrange, the last CC of the previous item to be used as initial CC of the one I put after it, as to not get CC jumps. If I have a note and want it to be played with a certain CC value, I have that CC value at note's playing time, so it will be there whether I split or not. Might be just the way I am used to work. Never had a problem there. I am not so much a fan of automatically added events, I think. But I understand what you mean. An option would be ok with me, and I might use it here and there.
|
|
|
01-29-2013, 04:44 PM
|
#224
|
Human being with feelings
Join Date: Jan 2010
Location: Kalispell
Posts: 14,759
|
Actually Mike, the Item 2 picture shows a good reason to use the last CC value when making a loop. For example, you've only got one CC event in the loop.
Last edited by Tod; 01-29-2013 at 04:51 PM.
|
|
|
01-29-2013, 04:51 PM
|
#225
|
-blänk-
Join Date: Jun 2008
Posts: 11,359
|
I think not. If that CC is used as fallback value, there'd be no change throughout the loop. The first part of the note inside the loop should ideally sound like the note in item 1 (regarding that CC) and then change to whatever the CC tells it, each time the loop iterates.
That's the problem. If there is no CC to tell how it was set in item 1 it's guesswork and depends on reasonable default values, except when you have something like medicine tactic describes.
|
|
|
01-29-2013, 04:53 PM
|
#226
|
Human being with feelings
Join Date: Jun 2009
Location: Croatia
Posts: 24,798
|
That would be valid only if there were absolutely no values of the same CC defined previously in the project.
|
|
|
01-29-2013, 04:59 PM
|
#227
|
Human being with feelings
Join Date: Aug 2012
Location: central Texas
Posts: 962
|
The initial value map would define the CC from time zero to the first actual event, eliminating the undefined portion, so chasing can create the illusion of a continuous envelope all the way through.
|
|
|
01-29-2013, 05:02 PM
|
#228
|
Human being with feelings
Join Date: Jan 2010
Location: Kalispell
Posts: 14,759
|
Quote:
Originally Posted by gofer
I think not. If that CC is used as fallback value, there'd be no change throughout the loop. The first part of the note inside the loop should ideally sound like the note in item 1 (regarding that CC) and then change to whatever the CC tells it, each time the loop iterates.
That's the problem. If there is no CC to tell how it was set in item 1 it's guesswork and depends on reasonable default values, except when you have something like medicine tactic describes.
|
Yes I know what you mean gofer but it could just as well be said that it might be advisable or desirable to loop the item at it's only slected volume.
Quote:
Originally Posted by EvilDragon
That would be valid only if there were absolutely no values of the same CC defined previously in the project.
|
Absolutely ED, that's exactly what I meant.
|
|
|
01-29-2013, 05:11 PM
|
#229
|
Human being with feelings
Join Date: Nov 2006
Posts: 2,533
|
Quote:
Originally Posted by Tod
Actually Mike, the Item 2 picture shows a good reason to use the last CC value when making a loop. For example, you've only got one CC event in the loop.
|
There is only 1 CC event in the loop, however, the event does not take place until halfway through the MIDI Note.
The the value of the CC was different at an earlier point in the song, that earlier value state would remain UNTIL you reached the CC entry in Item 2.
In other words, the Item would have a different loudness if looped, using your method, as opposed to letting the entire song play fro start to finish.
|
|
|
01-29-2013, 05:32 PM
|
#230
|
Human being with feelings
Join Date: Jan 2010
Location: Kalispell
Posts: 14,759
|
Quote:
Originally Posted by mikeroephonics
There is only 1 CC event in the loop, however, the event does not take place until halfway through the MIDI Note.
The the value of the CC was different at an earlier point in the song, that earlier value state would remain UNTIL you reached the CC entry in Item 2.
In other words, the Item would have a different loudness if looped, using your method, as opposed to letting the entire song play fro start to finish.
|
Oh no Mike, not at all, only after it loops would that particular CC event be in play.
Heh heh, this is all so hypothetical anyway, it'd be impossible to dream up all the possible scenarios. What works good under one scenario don't work well for another. Somewhere along the line the user has to take the responsibility.
However, I suppose there should be some safety nets if possible.
|
|
|
01-29-2013, 05:50 PM
|
#231
|
-blänk-
Join Date: Jun 2008
Posts: 11,359
|
Quote:
Originally Posted by Tod
Yes I know what you mean gofer but it could just as well be said that it might be advisable or desirable to loop the item at it's only slected volume.
|
Why? There is a CC mid note which should do a change, from how it's set before the loop to how it's set during the note. You hear that change when you play linearly, wouldn't you expect to hear that change also in each loop iteration?
Probably it's a workflow thing. When I set a loop it's to hear this particular time portion, to fine tune it. In this case I might concentrate on what this CC event does, how it changes the note volume mid note. I depend on it sounding the same as if I play right through, otherwise I couldn't evaluate the change.
That said, in practice I'd (like you most probably) have the initial value at note start, so it's not much of a problem. But if I now insert a note before the existing one into item 2, I'd again expect it to sound with the previous value, not the one set mid note. When played through and when looped.
|
|
|
01-29-2013, 06:56 PM
|
#232
|
Human being with feelings
Join Date: Aug 2012
Location: central Texas
Posts: 962
|
There's actually no need for a new file format for the initial value map. It could just be a MIDI file. That means there wouldn't even need to be a separate map editor -- we could just use the MIDI editor. The TCP context menu could contain a sub-menu to load, unload or edit a map. The map would be a special MIDI file where only the chase-able events matter, and in fact only those events at (source) time zero. The events would be sent when playing or chasing from time zero.
The whole thing is just a way to formalize and cleanup the "initial value MIDI item" idiom.
Last edited by medicine tactic; 01-29-2013 at 07:07 PM.
|
|
|
01-29-2013, 07:45 PM
|
#233
|
Human being with feelings
Join Date: Nov 2006
Posts: 2,533
|
Quote:
Originally Posted by Lawrence
So ... if you wrote a bunch of cc automation settings on a 16 bar midi clip, say using 4 different CC's, volume, pan, expression, whatever, and all those events or settings are in the first 8 bars of the clip, and later you decide to split that clip into two 8 bar clips and re-arrange them, you'd prefer to just lose all the CC automation settings on the split clip?
Not me personally, that would mean I'd have to repeat work that I've already done.
|
Make it a preference.
|
|
|
01-30-2013, 02:41 AM
|
#234
|
Human being with feelings
Join Date: Jan 2009
Posts: 559
|
Quote:
improved linear painting in drum modes
|
Log for v4.32 report this. I have just done a test, and I am still getting this bug in any midi mode:
Quote:
Originally Posted by miche
Sometimes, when using the paint a straight line of note mouse modifier, there are missing notes, as shown in the licecap below. I think it's always the last but one that is missing:
|
|
|
|
01-30-2013, 09:02 AM
|
#235
|
Human being with feelings
Join Date: Mar 2007
Posts: 21,551
|
Quote:
Originally Posted by mikeroephonics
Make it a preference.
|
Agree. I was just suggesting that it can potentially get messy without that option because in the course of some normal edits you leave some of your CC automation behind. But yes, make it a preference and everyone's happy.
One thing that maybe needs to be looked at during the midi love phase is to intentionally step out of this grid / pattern based midi production mode and just play some long midi parts in real time and then go about the normal job of choppping and editing and rearranging like you'd do with audio tracks, and take note of some of the issues, like some notes being split and duplicated and some CC automation being left behind along the way.
|
|
|
01-30-2013, 09:52 AM
|
#236
|
Human being with feelings
Join Date: Oct 2006
Location: Greece
Posts: 3,554
|
Quote:
Originally Posted by Lawrence
So ... if you wrote a bunch of cc automation settings on a 16 bar midi clip, say using 4 different CC's, volume, pan, expression, whatever, and all those events or settings are in the first 8 bars of the clip, and later you decide to split that clip into two 8 bar clips and re-arrange them, you'd prefer to just lose all the CC automation settings on the split clip?
Not me personally, that would mean I'd have to repeat work that I've already done.
|
In this scenario it is a good idea to keep the CC in separate parallel items. There are cases where it is a good idea to copy the initialization CC in item splits, and there are cases where it's not.
|
|
|
01-30-2013, 10:03 AM
|
#237
|
Human being with feelings
Join Date: Oct 2008
Posts: 708
|
This is just a suggestion!
If these viewpoints could be written down in pseudocode, then that would help the coders greatly.
such as....
If such-and-such, then
case 1: ......
case 2: ......
case n: ......
default: .....
elseif blah > blah-blah
other stuff
else
other option(s) here
end
Would also speed up development.
This CC stuff is a good example.
In other words, talk to the coders in their language.
Last edited by merdave; 01-30-2013 at 10:15 AM.
|
|
|
01-30-2013, 10:09 AM
|
#238
|
Human being with feelings
Join Date: Mar 2007
Posts: 21,551
|
Quote:
Originally Posted by Evan
There are cases where it is a good idea to copy the initialization CC in item splits, and there are cases where it's not.
|
Agree. I only bring it up because it's something directly relevant to "midi love" and it works contrary to my experience with other more mature sequencers by default. Like Mike says, it probably should be an option, but generally speaking, when I use CC's to make initial settings, I want those to persist in all cases until/unless I decide they shouldn't.
The example below is more what I'm accustomed to in that regard with other sequencers. You see a clip with CC volume and pan on it, static mix settings for that instrument. When I split the clip those settings always follow the split. Now granted (to your point), if you didn't want that to happen and there was no option, you'd have to manually delete them. If you did want that to happen and there was no option you'd have to manually recreate them.
So (like Mike says) the option would be best in either case.
Look at it from another angle. You have 8 bar clips across 12 tracks and you only want to use the last 4 bars of all that but all your initialization CC's are in the beginnings. Maybe you shouldn't have to move all those CC events on those clips to the right just to do that and keep them firing, but just trim the events from the left and keep working. In Reaper (unless again I'm missing a setting) when you trim past the CC event it's no longer active, like notes, when (some) CC's are really more like automation.
So in that case (a trim) I suppose it "chases" back to the CC event (in the same clip) that's been visually trimmed. In this case (or in Cubase), a node, like the "Bar" in Reaper.
Anyway, just some stuff to maybe consider during "midi love".
Last edited by Lawrence; 01-30-2013 at 10:28 AM.
|
|
|
01-30-2013, 10:29 AM
|
#239
|
Human being with feelings
Join Date: Aug 2012
Location: central Texas
Posts: 962
|
Quote:
Originally Posted by Lawrence
So ... if you wrote a bunch of cc automation settings on a 16 bar midi clip, say using 4 different CC's, volume, pan, expression, whatever, and all those events or settings are in the first 8 bars of the clip, and later you decide to split that clip into two 8 bar clips and re-arrange them, you'd prefer to just lose all the CC automation settings on the split clip?
Not me personally, that would mean I'd have to repeat work that I've already done.
|
You could just have a separate action to render chase values to events in the item selection. That is, serve item splitting and chase-rendering a la carte. Then you could make your own "split and render" macro, and choose when to use it over plain old split.
|
|
|
01-30-2013, 10:42 AM
|
#240
|
Human being with feelings
Join Date: Mar 2007
Posts: 21,551
|
Yeah I think I'm actually confusing everyone with this so here's a graphic example. There is only one "event" below for midi pan, the single node. That node directly relates to the "bar" event in Reaper. If this sequencer had an event list you'd only see the one event there.
I play the clip and it sends out my CC pan setting. Cool.
Then I trim the clip edge past the node (you can no longer even see the actual event) but it still sends out the CC pan setting at clip start, so my settings persist through all clip edits. So the "CC event" is not just a literal static event locked to a static timeline position, it's a CC "automation setting" that persists through any and all clip edits.
Does that make more sense? It works the same way in Cubase, it treats single CC's events like that like automation, not just static events that only fire if a visible clip section plays through them.
That behavior (I do think) is part of the overall "track based" midi thing... that that event is respected by the track even when there is no clip above it.
Last edited by Lawrence; 01-30-2013 at 10:51 AM.
|
|
|
Thread Tools |
|
Display Modes |
Linear Mode
|
Posting Rules
|
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
HTML code is Off
|
|
|
All times are GMT -7. The time now is 04:58 AM.
|