Go Back   Cockos Incorporated Forums > REAPER Forums > MIDI Hardware, Control Surfaces, and OSC

Reply
 
Thread Tools Display Modes
Old 11-22-2012, 09:07 AM   #41
Amazed
Human being with feelings
 
Amazed's Avatar
 
Join Date: Nov 2009
Location: Perth, W.A.
Posts: 1,646
Default

I think those of you that want to work with midi items is fine. For me I'd like to see the introduction of a new track type i.e. type midi. That understands what it's output channel and port is so it can work out what note descriptions to use. So I can use + & - to preview patches. IMO any channel that tries to be a master of all trades is never going to shine for all media types.
Amazed is offline   Reply With Quote
Old 11-22-2012, 10:25 AM   #42
ivansc
Human being with feelings
 
Join Date: Aug 2007
Location: Near Cambridge UK and Near Questembert, France
Posts: 18,941
Default

On a purely philosophical point, Med Tac, the "I don't see why I would need it, so why would anyone else find it useful" mindset is very easy to fall into. I find myself fighting against doing it all the time.

And of course you seem to be assuming that because YOU think that changing the MIDI editing bias in Reaper would cause you to lose control of your music, everyone else would.

What you have overlooked is that there is always more than one way of skinning a cat.
I have used both item based and track based MIDI editing and a combination of the two for around 20 odd years and have wound up being the most comfortable with a combination of the two. The implementation of this is so good I have stuck with a 30 year old computer OS just to be able to keep using it.
ivansc is offline   Reply With Quote
Old 11-22-2012, 11:10 AM   #43
medicine tactic
Human being with feelings
 
medicine tactic's Avatar
 
Join Date: Aug 2012
Location: central Texas
Posts: 962
Default

jnif:

I love the idea of a super-robust filter/MECP (and a Logical editor to put Cubase's to shame! )

First of all, for clarity and brevity, I'm going to introduce a term for the "track-based MIDI" algorithm that sits between the MIDI editor and the underlying items and translates event operations into operations on MIDI items: the MIDI agent.

From your comments, it looks like you're in favor of a multi-paradigm approach. That is, when one item is focused, the MIDI editor is in standard item-based editing mode. When two or more items are focused, the MIDI editor is in track-based editing mode. I'm going to simplify "two or more items are focused" to "all items are focused", which is the same as saying "no items are focused", or just "focus is off". (I don't think it makes sense to be able to focus subsets of a tracks's items -- to give the agent control over anything less than a complete track -- for the simple reason that the agent has the power to create (and possibly delete and glue) items, so any subset you define is subject to change without your consent.)

So:

Item-based editing: focus is on, MIDI agent is off

track-based editing: focus is off, MIDI agent is on

One problem with this multi-paradigm approach is that it's schizophrenic. When the MIDI agent is on, user operations on MIDI items should be deemphasized, because the MIDI agent is in charge of item administration. That is, you really shouldn't be too fussy about your items, because the agent will just modify them anyway. But when the MIDI agent is off, you're back in charge. Encouraged by REAPER's rich item feature set, you get your items arranged just so, with correct positions and lengths and colors and stacking, etc.. Then you do some more editing up in track-based MIDI land, and when you come back, the MIDI agent has completely messed up your arrangement. It's like a tasteless yet opinionated house-cleaning robot with no respect for your stuff: Either ditch your preferences for how your house is arranged, or ditch the robot. Keeping both is a recipe for frustration. Abstractions just don't work very well when you're constantly dropping beneath them to fiddle with what they're intended to hide.

Sonar correctly deemphasizes MIDI items, because ultimately it's in charge of them. It wants you to deal with MIDI primarily through its abstraction layer. This is the Right Thing within Sonar's philosophy. Sure, you can move items around, copy and paste them, change their size, etc., but only as a shorthand for moving the events themselves up in the MIDI editor. AFAICT, you can't even create MIDI items yourself -- you have to add events in the editor to initially create an item.

More eventually.

Last edited by medicine tactic; 11-22-2012 at 12:44 PM. Reason: missing word
medicine tactic is offline   Reply With Quote
Old 11-22-2012, 11:14 AM   #44
medicine tactic
Human being with feelings
 
medicine tactic's Avatar
 
Join Date: Aug 2012
Location: central Texas
Posts: 962
Default

I guess what I'm saying is, IMO we're gonna have to pick a side, folks.
medicine tactic is offline   Reply With Quote
Old 11-22-2012, 11:24 AM   #45
EvilDragon
Human being with feelings
 
EvilDragon's Avatar
 
Join Date: Jun 2009
Location: Croatia
Posts: 23,331
Default

No. YOU want to pick a side FOR THE REST OF US. Most of us who are pro-multi-item-editing don't agree with that. And devs don't necessarily have to listen to JUST YOU.
EvilDragon is offline   Reply With Quote
Old 11-22-2012, 11:37 AM   #46
medicine tactic
Human being with feelings
 
medicine tactic's Avatar
 
Join Date: Aug 2012
Location: central Texas
Posts: 962
Default

Quote:
Originally Posted by EvilDragon View Post
No. YOU want to pick a side FOR THE REST OF US. Most of us who are pro-multi-item-editing don't agree with that. And devs don't necessarily have to listen to JUST YOU.
I couldn't pick for anyone but myself, even if I wanted to. I'm just stating my case. The devs will do what they do, and I'll respect that.
medicine tactic is offline   Reply With Quote
Old 11-22-2012, 11:48 AM   #47
medicine tactic
Human being with feelings
 
medicine tactic's Avatar
 
Join Date: Aug 2012
Location: central Texas
Posts: 962
Default

The thing is, we can get, like, *almost* all the way there while still retaining the simplicity and determinism of focus, just by adding a few actions: directional focus-shifting and bounds movement.
medicine tactic is offline   Reply With Quote
Old 11-22-2012, 12:17 PM   #48
medicine tactic
Human being with feelings
 
medicine tactic's Avatar
 
Join Date: Aug 2012
Location: central Texas
Posts: 962
Default

EvilDragon: Honestly, I'm amazed you're so fervent, having only seen a few videos and never used Sonar yourself.

Making up your mind after watching a master at work is usually a bad idea. The thing about mastery is that by nature it makes its task look easy. Mastery is all about economy and efficiency. A master at work is a convincing argument for his tools. But it's the mastery that matters, not the class of tool. Tool *quality* matters, but mostly in the sense of defining a sort of plus-minus range.
medicine tactic is offline   Reply With Quote
Old 11-22-2012, 12:48 PM   #49
EvilDragon
Human being with feelings
 
EvilDragon's Avatar
 
Join Date: Jun 2009
Location: Croatia
Posts: 23,331
Default

I came to Reaper from FL Studio and Sonar 7, mister. It's not just videos I base my stance on.
EvilDragon is offline   Reply With Quote
Old 11-22-2012, 12:53 PM   #50
medicine tactic
Human being with feelings
 
medicine tactic's Avatar
 
Join Date: Aug 2012
Location: central Texas
Posts: 962
Default

That's ... unexpected. You've been so vague wrt what Sonar actually does. But I'll take your word for it.
medicine tactic is offline   Reply With Quote
Old 11-22-2012, 02:08 PM   #51
James HE
Human being with feelings
 
James HE's Avatar
 
Join Date: Mar 2007
Location: I'm in a barn
Posts: 4,415
Default

No fighting!

You kids better sit down and eat yer turkey!
James HE is offline   Reply With Quote
Old 11-22-2012, 02:44 PM   #52
jnif
Human being with feelings
 
jnif's Avatar
 
Join Date: Dec 2008
Posts: 2,042
Default

Quote:
Originally Posted by medicine tactic View Post
jnif:

I love the idea of a super-robust filter/MECP (and a Logical editor to put Cubase's to shame! )

First of all, for clarity and brevity, I'm going to introduce a term for the "track-based MIDI" algorithm that sits between the MIDI editor and the underlying items and translates event operations into operations on MIDI items: the MIDI agent.

From your comments, it looks like you're in favor of a multi-paradigm approach. That is, when one item is focused, the MIDI editor is in standard item-based editing mode. When two or more items are focused, the MIDI editor is in track-based editing mode. I'm going to simplify "two or more items are focused" to "all items are focused", which is the same as saying "no items are focused", or just "focus is off". (I don't think it makes sense to be able to focus subsets of a tracks's items -- to give the agent control over anything less than a complete track -- for the simple reason that the agent has the power to create (and possibly delete and glue) items, so any subset you define is subject to change without your consent.)

So:

Item-based editing: focus is on, MIDI agent is off

track-based editing: focus is off, MIDI agent is on

One problem with this multi-paradigm approach is that it's schizophrenic. When the MIDI agent is on, user operations on MIDI items should be deemphasized, because the MIDI agent is in charge of item administration. That is, you really shouldn't be too fussy about your items, because the agent will just modify them anyway. But when the MIDI agent is off, you're back in charge. Encouraged by REAPER's rich item feature set, you get your items arranged just so, with correct positions and lengths and colors and stacking, etc.. Then you do some more editing up in track-based MIDI land, and when you come back, the MIDI agent has completely messed up your arrangement. It's like a tasteless yet opinionated house-cleaning robot with no respect for your stuff: Either ditch your preferences for how your house is arranged, or ditch the robot. Keeping both is a recipe for frustration. Abstractions just don't work very well when you're constantly dropping beneath them to fiddle with what they're intended to hide.

Sonar correctly deemphasizes MIDI items, because ultimately it's in charge of them. It wants you to deal with MIDI primarily through its abstraction layer. This is the Right Thing within Sonar's philosophy. Sure, you can move items around, copy and paste them, change their size, etc., but only as a shorthand for moving the events themselves up in the MIDI editor. AFAICT, you can't even create MIDI items yourself -- you have to add events in the editor to initially create an item.

More eventually.
Thanks for checking out my FRs.
Unfortunately you seem to have misunderstood some parts of those FRs. And the new terminology you proposed makes this topic even more confusing.

The algorithm that extends items and creates new items automatically is not the same thing as "track-based MIDI".
I think "track-based MIDI" in Reaper could be seen simply as a way to easily activate-for-editing/show/hide/mute/transpose/qunatize/etc all items on same track. That means some kind of GUI features (and maybe also new actions) which help users to control all items on one track at once. In my proposal some of those GUI features are implemented in the controls of the MECP track/item hierarchy view.
Some users may include the automatic item extending/creation to the "track-based MIDI" feature, but in my opinion this kind of terminology can be missleading when applied to Reaper.
EDIT:
I should be more careful with explaining and defining these terms. The above definition of "track-based MIDI" is too narrow and can increase confusion. Maybe it would be better to stop using this "track-based MIDI" term altogether.

Reaper is different compared to many other DAWs because it allows overlapping MIDI items on same track. This is the reason why activation for editing in MIDI editor has to be different. Plain track based approach (like in many other DAWs), where you can activated only all items on track or none of the items on track for editing, will not work well in Reaper. In Reaper we need more fine grained activation for editing, i.e. item based activation instead of track based activation.

In Reaper it would be very convenient to be able to activate multiple items but not all items on same track for editing, especially when you have overlapping items on same track.

The automatic item extending/creating should be possible all the time. It should not depend on how many items you have activated for editing. It should work when you have no items activated, one item activated, two items activated, all items on one track activated, multiple items on multiple tracks activated, or all items in the project activated. It should work in every case.
But I understand that sometimes this automatic item manipulation can be bad. That is why I proposed the "Item Border Lock (IBL)" in my Multi-item MIDI editing FR. If user enabled "Item Borer Lock", it would prevent any automatic changes to the item borders. Basically if IBL is enabled, then item borders and new item creation would work just like in current Reaper v4.30. Notice that even when IBL is enabled you could still, for example, activate all items on one track for editing and edit all those items at the same time. Only automatic changes to item borders would be prevented.

jnif

Last edited by jnif; 11-23-2012 at 12:25 AM.
jnif is offline   Reply With Quote
Old 11-22-2012, 03:51 PM   #53
medicine tactic
Human being with feelings
 
medicine tactic's Avatar
 
Join Date: Aug 2012
Location: central Texas
Posts: 962
Default

Quote:
Originally Posted by jnif
Thanks for checking out my FRs.
Unfortunately you seem to have misunderstood some parts of those FRs. And the new terminology you proposed makes this topic even more confusing.

The algorithm that extends items and creates new items automatically is not the same thing as "track-based MIDI".
I would say it is the defining characteristic. It is the one absolutely necessary addition if more than one item can be focused. Also, if the algorithm has the power to create items, it needs the power to destroy and glue items as well.

Quote:
I think "track-based MIDI" in Reaper could be seen simply as a way to easily activate-for-editing/show/hide/mute/transpose/qunatize/etc all items on same track.
I think this muddies the issue, mixing the core with the constellation of features surrounding it.

And we need to make a distinction between individual edits and batch operations. Batch operations, (quantizing, scaling velocities, etc. -- operations that can be applied to whole items at a time) aren't a problem, even in REAPER as it is now. It's the individual edits that are a problem when more than one item has focus.

Quote:
That means some kind of GUI features (and maybe also new actions) which help users to control all items on one track at once. In my proposal some of those GUI features are implemented in the controls of the MECP track/item hierarchy view. Some users may include the automatic item extending/creation to the "track-based MIDI" feature, but in my opinion this kind of terminology can be missleading when applied to Reaper.

Reaper is different compared to many other DAWs because it allows overlapping MIDI items on same track.
I know for sure that Cubase, Logic, Sonar, and Studio One all allow overlapping MIDI items. Probably most DAWs do.

Quote:
This is the reason why activation for editing in MIDI editor has to be different. Plain track based approach (like in many other DAWs), where you can activated only all items on track or none of the items on track for editing, will not work well in Reaper.
I think track-based editing is actually the odd-man out. Sonar is the only one I know of.

Quote:
In Reaper we need more fine grained activation for editing, i.e. item based activation instead of track based activation.

In Reaper it would be very convenient to be able to activate multiple items but not all items on same track for editing, especially when you have overlapping items on same track.

The automatic item extending/creating should be possible all the time. It should not depend on how many items you have activated for editing. It should work when you have no items activated, one item activated, two items activated, all items on one track activated, multiple items on multiple tracks activated, or all items in the project activated. It should work in every case.
I think the subset of items you activate becomes meaningless when the algorithm has the power to create and destroy items. It only makes sense to me to operate on a single item or a complete track (again, I'm talking about individual edits here, not batch operations, which aren't a problem.)

Quote:
But I understand that sometimes this automatic item manipulation can be bad. That is why I proposed the "Item Border Lock (IBL)" in my Multi-item MIDI editing FR. If user enabled "Item Borer Lock", it would prevent any automatic changes to the item borders. Basically if IBL is enabled, then item borders and new item creation would work just like in current Reaper v4.30. Notice that even when IBL is enabled you could still, for example, activate all items on one track for editing and edit all those items at the same time. Only automatic changes to item borders would be prevented.
Even if the borders are locked, stacked items are still a problem.

Please don't confuse my terseness for hostility: I was just responding as quickly as I could!
medicine tactic is offline   Reply With Quote
Old 11-22-2012, 05:05 PM   #54
Amazed
Human being with feelings
 
Amazed's Avatar
 
Join Date: Nov 2009
Location: Perth, W.A.
Posts: 1,646
Default

Ill move more toward what I want to do instead of how to do it. I want to work on a 3 part piece. Drums bass and piano. My piano is on preset 1 channel 1 on port 1. My bass on preset 5 on channel 3 on port 2 and my drums on preset 14 channel 10 on port 1.

So I'd like to open the piano roll and be able to paint the relevant events in that one window. I don't want to have to bounce between different windows for different channels and ports or tracks in this case. I have a whole bank of basses on channel 3 on port 2 and I want to preview them in context. In this one window I want to cycle all my events for channel 3 on port 2 through the presets 5 thru 11 while the piece is playing and I want to rather use the drums Ive got on preset 5 of bank 2 on channel 10 port 1. No, changed my mind. The other drums are better.

Now that is a real life scenario for me. I wouldn't say how to implement it in Reaper. I have some ideas of an instrument palette where an 'instrument' encapsulates a bank, preset, port and channel.Then you can just 'dip' your pen in the piano and paint but that's just a conceptual idea. One day in the future .. far far away.
Amazed is offline   Reply With Quote
Old 11-22-2012, 06:53 PM   #55
Tod
Human being with feelings
 
Tod's Avatar
 
Join Date: Jan 2010
Location: Just outside of Glacier National Park
Posts: 12,601
Default

Personally for me all I need or want is track based midi editing. However, there are a lot of good folks here who use and need item based editing. So for me if there was an option or switch to just switch between the two, it would be great. Also I'd like the Filter box to reflect this, when in track based mode it would only show the tracks and no items at all.

Another little red herring, Note Names. It would be great if each track could have it's own Note Names and this would change to the appropriate Note Names with each track selection.

Also I'd like to see the current menu selection Contents become a box where you can select or unselect midi tracks at will and then hit OK when done.

__________________
Kontakt Vid Tutorials->Create Outputs / Create Templates -|- SMDrums Free drums -|- Elk Video Productions -|- Tod's Music
Tod is online now   Reply With Quote
Old 11-22-2012, 07:21 PM   #56
Lawrence
Human being with feelings
 
Join Date: Mar 2007
Posts: 21,497
Default

My ... general subjective observation? ... of this recurring discussion of item vs. track and the (imo, false) idea that being limited to only opening or editing one item at a time is somehow beneficial to editing...

When you edit an audio clip does it hide all the other audio clips on the track? Not that I'm aware of. Is that a issue for anyone? Not that I can see.

When you zoom into a track to edit an audio clip on that track does the mere existence of the other clips on the track somehow interfere with editing that clip? No. On the contrary, it helps because you don't have to keep zooming to them, you can - if you prefer - let the track scroll through them while it plays... and stop and edit anything on the track.

This is exactly how Reaper works right now for audio editing. Why, for what reason exactly, should a midi editor employ a completely different edit model?

A "secondary editor window" is nothing more than an enlarged view of the track(s) and data, making a "big track" for detailed editing. What advantage is there to a secondary view of data when it can't - ever? - actually contain all the track data for immediate and/or collective random access editing? None that I can see. Not a single one.

Bottom line? It's all - just like editing audio on a track - a simple matter of access and edit focus.

The supposed disadvantages to what's called "track based" are - imo, mmv - mostly imaginary.

It gets a bit overwhelming because the same examples against it keep coming up, examples that have been shown to not be actually realistic time and time again with graphics and demonstrations. But every time this topic comes up you see the same arguments against it... and only ED seems to be willing to continuously repeat the contrary examples over and over and over.

Subjectively speaking, one of the biggest issues with Reaper's "item based" midi editing is one that rarely even gets mentioned, the really quite unusual truncated timeline display?

Anyway, as much as I'd like to contribute to this if it comes up in the beta, I'm simply really tired of explaining it all (what seems to me to be clearly obvious benefits, and why the repetitive counter-examples against it don't actually hold up under scrutiny, on balance) over and over again.

Thank god ED actually never tires of that.

Last edited by Lawrence; 11-22-2012 at 07:53 PM.
Lawrence is offline   Reply With Quote
Old 11-22-2012, 08:30 PM   #57
medicine tactic
Human being with feelings
 
medicine tactic's Avatar
 
Join Date: Aug 2012
Location: central Texas
Posts: 962
Default

Quote:
Originally Posted by Lawrence View Post
My ... general subjective observation? ... of this recurring discussion of item vs. track and the (imo, false) idea that being limited to only opening one item is somehow beneficial to editing...

When you edit an audio clip does it hide all the other audio clips on the track? Not that I'm aware of. Is that a issue for anyone? Not that I can see.

When you zoom into a track to edit an audio clip on that track does the mere existence of the other clips on the track somehow interfere with editing that clip? No. On the contrary, it helps because you don't have to keep zooming to them, you can - if you prefer - let the track scroll through them while it plays... and stop and edit anything on the track.

This is exactly how Reaper works right now for audio editing. Why, for what reason exactly, should a midi editor employ a completely different edit model?
There's a huge misunderstanding here. The ability to open any collection of MIDI items in the MIDI editor is a given. I want it. We already have it. It's a done deal. That's not what we're talking about.

All I'm arguing is that REAPER retain a simple, deterministic, single focus. That's it. The rest is details. Almost every DAW's MIDI editor is a riff on this concept. The exception, to my knowledge, is Sonar. It replaced the simple, deterministic single focus with an abstraction layer that manages items behind the scenes. This is good for some things and not for others. I personally do not want it, and do not think it would be a good fit for REAPER.

Quote:
A "secondary editor window" is nothing more than an enlarged view of the track and data, making a "big track" for detailed editing. What advantage is there to a secondary view of data when it can't - ever? - actually contain all the track data for immediate and/or collective editing? None that I can see. Not a single one.
Again, you seem to be arguing with not me.

Quote:
Bottom line? It's all - just like editing audio on a track - a simple matter of access and focus.
Word!

Quote:
The supposed disadvantages to what's called "track based" are - imo, mmv - mostly imaginary.
The software is creating, deleting, resizing and gluing items behind the scenes, and deciding which items receive events. This is what happens, and is not imaginary. Whether it's a disadvantage is a matter of opinion.

Quote:
It gets a bit overwhelming because the same examples against it keep coming up, examples that have been shown to not be actually realistic time and time again with graphics and demonstrations. But every time this topic comes up you see the same arguments against it... and only ED seems to be willing to continuously repeat the contrary examples over and over and over.
Can you give me a specific example of how I'm being unrealistic? I genuinely want my mental model to be as accurate as possible.

Quote:
Subjectively speaking, one of the biggest issues with Reaper's "item based" midi editing is one that rarely even gets mentioned, the really quite unusual truncated timeline display?
Yeah, that is strange...

Quote:
Anyway, as much as I'd like to contribute to this if it comes up in the beta, I'm simply really tired of explaining it all over and over again. Thank god ED actually never tires of that.
You never seem to tire of explaining how you tire of explaining though
medicine tactic is offline   Reply With Quote
Old 11-22-2012, 09:19 PM   #58
medicine tactic
Human being with feelings
 
medicine tactic's Avatar
 
Join Date: Aug 2012
Location: central Texas
Posts: 962
Default

I think the whole issue stems from a misunderstanding of focus. The two things all formulations of focus seem to have in common are 1) the user chooses which item has focus, and 2) the focused item is the one that receives events under normal circumstances. There's almost nothing to it. And yet removing it causes a profound shift.

Some DAWs allow you to select events in unfocused items, and drag them or delete them or quantize them or whatever. This still falls within single-focus, item-based editing.

Some DAWs allow you to drag events from one item to another. Same.

Any definable set of events in the whole project can be batch-operated on, and this will not violate single-focus item-based editing.

Select all C#2's with a velocity between 67 and 73 and transpose them -13 semitones? Does not violate single-focus item-based editing.

Just want to draw events on an infinite grid and let the software worry about how to itemize them? Now we have a problem.

But with an expressive set of actions for item bounds movement and focus-shifting, you should be able to define a behavior that suits you just fine, and REAPER would retain single-focus item-based editing.
medicine tactic is offline   Reply With Quote
Old 11-22-2012, 09:22 PM   #59
Lawrence
Human being with feelings
 
Join Date: Mar 2007
Posts: 21,497
Default

Quote:
Originally Posted by medicine tactic View Post
Can you give me a specific example of how I'm being unrealistic? I genuinely want my mental model to be as accurate as possible.
Search through and read any or all of the multiple previous threads about it. There are lots of specific examples in them.

I'll summarize the result of all that below (as I saw it play out anyway, make up your own mind) ...
"There is absolutely nothing that (as a practical matter for editing midi) you can do in Reaper's item based system that can't also be done just as easily or even easier in some cases, in a well designed "track based" system...

... you lose no current editing functionality ...

... but ... you definitely cannot say the opposite...

... there are good things the track based systems easily allow that Reaper's item based system does not allow ...

... so a logical conclusion would be that it's pretty much all 'upside'."
Unless the above conclusion is false, and I don't personally believe it is, but you can make up your own mind by reading it all, I don't see any logical reason for debate... unless some people actually prefer "less flexible" or "less functionality".

And sure, you can seek out and cherry pick potential corner case problems that actually don't exist in the better designs, but even given those, it always still balances out pretty easily to "better editing."... the only relevant point.

And of course, not everyone seeing the same examples will reach the same exact conclusions.

A good 50% of the disagreements in those threads were people who actually didn't understand how it works as a really good or best case, making assumptions based on some older maybe bad model they used 10 years ago.

Personally, mmv and all that, I don't see anything philosophical about the discussion. It's better (more flexible, faster) midi editing plain and simple... as a purely practical matter.

I should add, again as I see it, mmv, the debate (if any at all) doesn't actually rest with "Is it better...", in my mind that's easily true... but with "Is it worth it in Reaper, spending the resources or time to do it..." ... which is, in my mind anyway, a perfectly reasonable area of discussion. If most users don't actually want it, they maybe shouldn't do it, if it would take away from something else that most users actually want. I have no bone to pick with that.

Last edited by Lawrence; 11-22-2012 at 09:44 PM.
Lawrence is offline   Reply With Quote
Old 11-22-2012, 09:52 PM   #60
Amazed
Human being with feelings
 
Amazed's Avatar
 
Join Date: Nov 2009
Location: Perth, W.A.
Posts: 1,646
Default

Quote:
Originally Posted by medicine tactic View Post
There's a huge misunderstanding here. The ability to open any collection of MIDI items in the MIDI editor is a given. I want it. We already have it. It's a done deal. That's not what we're talking about.though
As an aside gentlemen if one of you would please take a moment to educate me on that very point. How exactly does one edit an entire track of mid items at once in the midi editor because even though I multi select items in any given track and then invoke the editor. Only 1 item of all those I selected is ever editable. The others are just grayed out.
The same goes for multiple tracks. How do I get all those items into the mide editor to edit at once?

Thanks.

Because the midi filter is on by default it seems? Anyway I got it going.

Last edited by Amazed; 11-22-2012 at 11:17 PM. Reason: Coz I didnt read the manual.
Amazed is offline   Reply With Quote
Old 11-22-2012, 10:12 PM   #61
medicine tactic
Human being with feelings
 
medicine tactic's Avatar
 
Join Date: Aug 2012
Location: central Texas
Posts: 962
Default

Lawrence: Forgive me, but that's an enormous evasion. You could have saved yourself a lot of typing by giving one concrete example.

Quote:
... there are good things the track based systems easily allow that Reaper's item based system does not allow ...
Of course REAPER falls short. It's young. It's maturing. You should be pitting an idealized item-based system against an idealized track-based system. Which is nonsense anyway. Theoretical-capability-wise, they're equals. Their differences are complimentary, and a matter of preference.

Quote:
Unless the above conclusion is false, and I don't personally believe it is, but you can make up your own mind by reading it all, I don't see any logical reason for debate... unless some people actually prefer "less flexible" or "less functionality".
It's not even false. There's no substance there at all.
medicine tactic is offline   Reply With Quote
Old 11-22-2012, 10:17 PM   #62
Lawrence
Human being with feelings
 
Join Date: Mar 2007
Posts: 21,497
Default

Quote:
There's a huge misunderstanding here. The ability to open any collection of MIDI items in the MIDI editor is a given. I want it. We already have it. It's a done deal. That's not what we're talking about.
Yes, there certainly is. Your complete misunderstanding of what the "track based" FR actually asks for, the problems it seeks to solve.

And I am not "arguing" with you. I'm only asking you to (please?) read the actual "track based midi editing" FR's so you at least know exactly what those people are asking for and why.

You may still disagree with it, but at least you'll actually know what they're asking for. Its not a "done deal".

And it's actually not about Reaper, it's only about one general editing method vs another. Reaper isn't the only DAW with item-based midi editing.

Happy Thanksgiving. I think I've written way more than necessary here.
Lawrence is offline   Reply With Quote
Old 11-22-2012, 10:20 PM   #63
medicine tactic
Human being with feelings
 
medicine tactic's Avatar
 
Join Date: Aug 2012
Location: central Texas
Posts: 962
Default

Quote:
Originally Posted by Amazed View Post
As an aside gentlemen if one of you would please take a moment to educate me on that very point. How exactly does one edit an entire track of mid items at once in the midi editor because even though I multi select items in any given track and then invoke the editor. Only 1 item of all those I selected is ever editable. The others are just grayed out.
The same goes for multiple tracks. How do I get all those items into the mide editor to edit at once?

Thanks.
Heh, no, you're right. That's the way it is. But that's just a limitation of REAPER's ME's current incarnation, not an inherent limitation of the item-based approach.
medicine tactic is offline   Reply With Quote
Old 11-22-2012, 10:23 PM   #64
medicine tactic
Human being with feelings
 
medicine tactic's Avatar
 
Join Date: Aug 2012
Location: central Texas
Posts: 962
Default

Quote:
Originally Posted by Lawrence View Post
Yes, there certainly is. Your complete misunderstanding of what the "track based" FR actually asks for, the problems it seeks to solve.

And I am not "arguing" with you. I'm only asking you to (please?) read the actual "track based midi editing" FR's so you at least know exactly what those people are asking for and why.

You may still disagree with it, but at least you'll actually know what they're asking for. Its not a "done deal".

And it's actually not about Reaper, it's only about one general editing method vs another. Reaper isn't the only DAW with item-based midi editing.

Happy Thanksgiving. I think I've written way more than necessary here.
I've read the feature requests extensively. I'm pretty sure my mental model is correct. I'm begging you to point out where I'm wrong. It would surely take less typing than what you've already written.
medicine tactic is offline   Reply With Quote
Old 11-22-2012, 10:37 PM   #65
Lawrence
Human being with feelings
 
Join Date: Mar 2007
Posts: 21,497
Default

Quote:
Originally Posted by medicine tactic View Post
I'm begging you to point out where I'm wrong.
No thanks. I'd rather submit and move along at this point knowing how these kinda things tend to go on forever.

You're right, I'm wrong, finis.

If you find that patronizing or similar, and it's actually not meant to be, we can also just politely agree to disagree (or whatever actually works) and get the same result, a conclusion.

Thanks man. I did enjoy our conversation.
Lawrence is offline   Reply With Quote
Old 11-22-2012, 11:45 PM   #66
medicine tactic
Human being with feelings
 
medicine tactic's Avatar
 
Join Date: Aug 2012
Location: central Texas
Posts: 962
Default

Quote:
Originally Posted by Lawrence View Post
No thanks. I'd rather submit and move along at this point knowing how these kinda things tend to go on forever.

You're right, I'm wrong, finis.

If you find that patronizing or similar, and it's actually not meant to be, we can also just politely agree to disagree (or whatever actually works) and get the same result, a conclusion.

Thanks man. I did enjoy our conversation.
Fair enough. I realize you'll have to take this on faith for now -- this is The Internet after all -- but my motives really are the pursuit of a mutual understanding of the best future for REAPER. I've even been known to change my mind in the face of evidence. Ah well. Until next time!
medicine tactic is offline   Reply With Quote
Old 11-23-2012, 03:54 AM   #67
ivansc
Human being with feelings
 
Join Date: Aug 2007
Location: Near Cambridge UK and Near Questembert, France
Posts: 18,941
Default

Quote:
Originally Posted by medicine tactic View Post
I guess what I'm saying is, IMO we're gonna have to pick a side, folks.
Having apparently not read or ignored my earlier post commenting on your tunnel vision regarding this, maybe you should learn a little more than a brief gloss over Cakewalk's take on this and examine the other methods of implementing this adopted by other software houses.
There is absolutely no need whatsoever to "pick a side".

ED, myself and others have tried to point out to you that you ARE looking at this from an ultra limited perspective and relentlessly insisting on hammering home YOUR take on this as if it is the only viable or correct one.

I reiterate something I said earlier - sometimes you need to know that you don't know enough.
You apparently don't or are choosing to ignore it.

This is not intended to be patronising or as a flame, just trying to make you see how you are coming over at present.
My kindest advice to you would be that you examine the way other companies have achieved a good balance in MIDI editing and take it from there.

Sonar MIDI editing I found almost as frustrating as Reaper's despite being a Sonar owner from 3.0 right up to 8.5.3, when I finally gave up in disgust.

Once again I sincerely hope you will not take this post as insulting, it is not intended to be


P.S. I have no idea what terminology you are using here: << focus is on, MIDI agent is off >>
focus and MIDI agent mean nothing to me in this context.

IF what you mean by focus is "I can highlight the bit of a MIDI track I want to work on", it does make some sort of sense, but what do you mean by MIDI agent?
Maybe its just me, but in some forty odd years of working with MIDI I an struggling with your terminology, as I suspect are others.

Last edited by ivansc; 11-23-2012 at 04:06 AM.
ivansc is offline   Reply With Quote
Old 11-23-2012, 04:09 AM   #68
gofer
-blänk-
 
gofer's Avatar
 
Join Date: Jun 2008
Posts: 11,159
Default

The internet. Someone says he sees complications with the holy track based cow and wants them discussed. And folks smell heresy. Why does the course of this thread remind me of threads where someone on a DAW forum dares to criticize the DAW the forum is about and gets grilled? Is it really a "Someone's right, other one's wrong" affair? Why do we have to go there every time?


To say it for the umpteenth time:
I understand the benefits people see in the track based approach. Can we just premise that? I don't intend to undermine the request, but I as well see problems to it. I'd like some thinking to be done to find solutions - not to undermine but, in contrary, to put the request on some solid grounds.
Yes, the OP plays devil's advocate and asks the question whether dealing with the problems is worth it at all, because the solutions he can see don't seem to fit with Reaper's general approach to things. Yet I don't think he misunderstands the problems the request tries to solve. Actually, I think he understands very well the problems that need to be solved to make the request a reality.

Most of the answers we get are ranging from "Track based editing - yay, it's good" (who'd have thunk?) over "How dare you" (well, he does) to "You don't get it" (is that so?), but barely anyone tries to tackle the question: How can it be done in Reaper?
I am very thankful that there are some exceptions to be found in this thread trying to break that circle race.



The problems are not regarding things like quantize, velocity changes/transposing/scaling or other edits on existing data across multiple items (that can even be done in a strictly item based approach, Logic does that for a long time and in a very comfortable way - not just track wide but for all selected MIDI items, call it project based, if you want, but in fact it's working strictly on individual region source data - in Reaper that'd be take sources). It's when new events are created when the problem some people try to point at here come into play. So much for the analogy with audio editing (which is item based - actually take source based, to at least once use the correct terminology). You can't add "events" to audio in Reaper, only by adding items (takes).


If Sonar or some other DAW does it right and you know it, can please someone start explaining what it does and how it's solutions can be translated into Reaper, instead of just continue the "other DAWs do it right" chant?
gofer is offline   Reply With Quote
Old 11-23-2012, 06:40 AM   #69
Amazed
Human being with feelings
 
Amazed's Avatar
 
Join Date: Nov 2009
Location: Perth, W.A.
Posts: 1,646
Default

Quote:
Originally Posted by gofer View Post
Most of the answers we get are ranging from "Track based editing - yay, it's good" (who'd have thunk?) over "How dare you" (well, he does) to "You don't get it" (is that so?), but barely anyone tries to tackle the question: How can it be done in Reaper?
I thought 'track based editing' WAS a proposed solution. Not a problem that requires a solution? i.e. the answer to the question. mmm.

I will say again that I believe we'd all be better off if we agreed on the validity of the problem before we propose what we believe to be our personally god given solution to the problem that is so often misunderstood anyway. Rule 1. Validate the requirement.
Amazed is offline   Reply With Quote
Old 11-23-2012, 07:41 AM   #70
ivansc
Human being with feelings
 
Join Date: Aug 2007
Location: Near Cambridge UK and Near Questembert, France
Posts: 18,941
Unhappy

gofer - not sure how many times we have to keep giving examples of what the advantages are (TO US - not all users) of having the option to work in track based mode.

I have tried very hard to keep my comments objective and to the point,
There seems to be a tendency on here for the critics to wade in with a very narrow view of what us track-based edit fiends are wanting to achieve.

It would be a fair bit of work and take time I really don't have at this time of the year to consolidate all the various posts on this subject that have already detailed the advantages, but I suppose if people really need spoon feeding that much I would rather do it than get labelled as a wild eyed track based editing fanboi.

Whilst I appreciate there has to be balance here, it does seem like folks like myself and ED who have been promoting and discussing this for very very long time have already done our homework, so there is inevitably going to be a little irritation when we get posts that seem like they come from people who appear to take no notice whatsoever of what has gone before.

To be blunt, I am likely to go into lurk-only mode with the way this forum is developing these days.
Everything seems to turn into a fight, regardless of the intent.
ivansc is offline   Reply With Quote
Old 11-23-2012, 08:39 AM   #71
medicine tactic
Human being with feelings
 
medicine tactic's Avatar
 
Join Date: Aug 2012
Location: central Texas
Posts: 962
Default

Quote:
Originally Posted by ivansc View Post
Having apparently not read or ignored my earlier post commenting on your tunnel vision regarding this, maybe you should learn a little more than a brief gloss over Cakewalk's take on this and examine the other methods of implementing this adopted by other software houses.
There is absolutely no need whatsoever to "pick a side".

ED, myself and others have tried to point out to you that you ARE looking at this from an ultra limited perspective and relentlessly insisting on hammering home YOUR take on this as if it is the only viable or correct one.

I reiterate something I said earlier - sometimes you need to know that you don't know enough.
You apparently don't or are choosing to ignore it.

This is not intended to be patronising or as a flame, just trying to make you see how you are coming over at present.
My kindest advice to you would be that you examine the way other companies have achieved a good balance in MIDI editing and take it from there.

Sonar MIDI editing I found almost as frustrating as Reaper's despite being a Sonar owner from 3.0 right up to 8.5.3, when I finally gave up in disgust.

Once again I sincerely hope you will not take this post as insulting, it is not intended to be


P.S. I have no idea what terminology you are using here: << focus is on, MIDI agent is off >>
focus and MIDI agent mean nothing to me in this context.

IF what you mean by focus is "I can highlight the bit of a MIDI track I want to work on", it does make some sort of sense, but what do you mean by MIDI agent?
Maybe its just me, but in some forty odd years of working with MIDI I an struggling with your terminology, as I suspect are others.
You're absolutely right, and I'm sorry. I was taking an extrememly narrow view -- that Sonar is the definition of "track-based", or at least the only instance we can point to -- and focusing all my energy on that. In my defense, that is how ED sells the feature, so perhaps I can be forgiven a little for taking it that way. My error was then compounded by the fact that Sonar really *is* the odd man out, presenting a very convenient line in sand. I then interpreted all the other FR's through that lens, inventing a consensus where there isn't one.

I reacquainted myself with the behavior of all the DAWs I could get my hands on last night (Cubase, Studio One, Logic, FL Studio, REAPER and Sonar), and there really is a continuum. I would still say every one of those besides Sonar is item-based in the strictest sense, some of them, Logic in particular, do an extremely convincing impression of a track-based system. It's no wonder there's so much confusion around terminology.

So my comments in this thread are mostly me saying "REAPER's MIDI editing shouldn't become identical to Sonar's!" Which there was never much chance of anyway.

Sorry everyone! Let's lay this one to rest.
medicine tactic is offline   Reply With Quote
Old 11-23-2012, 08:53 AM   #72
medicine tactic
Human being with feelings
 
medicine tactic's Avatar
 
Join Date: Aug 2012
Location: central Texas
Posts: 962
Default

Quote:
Originally Posted by gofer View Post
The internet. Someone says he sees complications with the holy track based cow and wants them discussed. And folks smell heresy. Why does the course of this thread remind me of threads where someone on a DAW forum dares to criticize the DAW the forum is about and gets grilled? Is it really a "Someone's right, other one's wrong" affair? Why do we have to go there every time?


To say it for the umpteenth time:
I understand the benefits people see in the track based approach. Can we just premise that? I don't intend to undermine the request, but I as well see problems to it. I'd like some thinking to be done to find solutions - not to undermine but, in contrary, to put the request on some solid grounds.
Yes, the OP plays devil's advocate and asks the question whether dealing with the problems is worth it at all, because the solutions he can see don't seem to fit with Reaper's general approach to things. Yet I don't think he misunderstands the problems the request tries to solve. Actually, I think he understands very well the problems that need to be solved to make the request a reality.

Most of the answers we get are ranging from "Track based editing - yay, it's good" (who'd have thunk?) over "How dare you" (well, he does) to "You don't get it" (is that so?), but barely anyone tries to tackle the question: How can it be done in Reaper?
I am very thankful that there are some exceptions to be found in this thread trying to break that circle race.



The problems are not regarding things like quantize, velocity changes/transposing/scaling or other edits on existing data across multiple items (that can even be done in a strictly item based approach, Logic does that for a long time and in a very comfortable way - not just track wide but for all selected MIDI items, call it project based, if you want, but in fact it's working strictly on individual region source data - in Reaper that'd be take sources). It's when new events are created when the problem some people try to point at here come into play. So much for the analogy with audio editing (which is item based - actually take source based, to at least once use the correct terminology). You can't add "events" to audio in Reaper, only by adding items (takes).


If Sonar or some other DAW does it right and you know it, can please someone start explaining what it does and how it's solutions can be translated into Reaper, instead of just continue the "other DAWs do it right" chant?
Thanks gofer! I was beginning to think I was crazy.
medicine tactic is offline   Reply With Quote
Old 11-23-2012, 09:49 AM   #73
Lawrence
Human being with feelings
 
Join Date: Mar 2007
Posts: 21,497
Default

@Gofer: Here's a common example.

I'm editing midi in the midi editor and I want to select and edit data that happens to reside across multiple tracks and multiple clips all at once in the midi editor. Can't do it in Reaper at all, can easily do it in Cubase and some others.

Now I personally don't intend to use the term "item based" in a way that suggests "that's impossible in any item based system", to cause a philosophical debate about what an "item" actually is or isn't. I use it to say (apparently?) some limitations like the above in Reaper are because the edit container (including the physical timeline) in the editor is pretty much always limited to a single item's boundary.

So for me - and I cannot speak for anyone else - "Item Based" only ever meant "That's where the editing is contained, or limited to, the item borders." The bold text above is not finger-pointing or "get this now!" bold text, it's intended just to emphasize the apparent cause and effect relationship in the current design.

I do think some people get too caught up on the terms which is why at some point I kinda started using the phrase "collective editing" because it's more accurate imo.

If Reaper could collectively edit across multiple tracks and multiple clips, at random, at will, in the key and list editors, nobody would care what you call it. Call it "Enhanced Item Based Editing".

And I actually agree. The phrase "track based" has become a red herring that causes phlosophical discussions about what an item is or isn't when the crux of the problem is just function... and (I assume) those functions can be also done in an item based system. It's a bit of a paradox though. If the editing can actually range outside of an item and across multiple discreet items and tracks, it wouldn't make much sense to call it item based (which kinda only really meant "item limited" in this context) anymore, to me, mmv.

I wouldn't necessarily - in this particular context - call Logic "item based" if editing can actually range across items, at a higher level than a single item. But if the functions are there, nobody will really care what it's called.

Last edited by Lawrence; 11-23-2012 at 10:31 AM.
Lawrence is offline   Reply With Quote
Old 11-23-2012, 10:09 AM   #74
Tod
Human being with feelings
 
Tod's Avatar
 
Join Date: Jan 2010
Location: Just outside of Glacier National Park
Posts: 12,601
Default

I think what we really need in this regard, is a clear picture of what all the details are for:

>The advantages that Track based Midi Editing poses.

>The disadvantages that Track based Midi Editing poses for working with individual items.

For me, the advantages are very clear.

However, the disadvantages are not clear to me at all, since I don't use looping and all my midi clips are full song items. What we need here are some good clear details from those who really know, that will dispel myth from reality. I seem to remember a while ago, gofer laid out some ideas on this but I don't recall the thread or what he said.
__________________
Kontakt Vid Tutorials->Create Outputs / Create Templates -|- SMDrums Free drums -|- Elk Video Productions -|- Tod's Music
Tod is online now   Reply With Quote
Old 11-23-2012, 10:17 AM   #75
Lawrence
Human being with feelings
 
Join Date: Mar 2007
Posts: 21,497
Default

I personally think - mmv - we need to just stop using those terms "Item Based" and "Track Based" and just simply direct the focus to the actual missing functionality.

The terms seem to have arose out of general attempt at some kind of description of varying edit models, they're not all that important really, the terms themselves. They seem to only cause confusion.

What's important is the missing functionality.
Lawrence is offline   Reply With Quote
Old 11-23-2012, 10:41 AM   #76
jnif
Human being with feelings
 
jnif's Avatar
 
Join Date: Dec 2008
Posts: 2,042
Default

Let's try to list the general requirements first.
I will try not to use any terminology that could be interpreted in a wrong way.
We can try to make the complete requirement list first and only after that decide whether it is possible (or useful) to implement all of them or only some of them in Reaper.

1. Edit multiple MIDI items at the same time interactively directly in Piano Roll View. (This does NOT include batch processing, scripts, or separate edit windows/panels like quantize/transpose windows.)

2. A method to easily select which MIDI items are active for editing. The active items can be on same or different track. And the items can be in different time locations, or partially overlapping, or completely overlapping.

3. Display full project timeline and grid lines in the Piano Roll View. Grid and timeline should be visible also in empty areas between items. It should be possible to scroll the view to any location of the project in Piano Roll View even if there are no MIDI items there.

4. Create new items automatically when MIDI events are added to empty area of a track.

5. Extend MIDI items automatically when MIDI events are moved outside existing item, or added close to the edge of existing item.

6. Option to disable automatic item creation and extending described in requirements 4 and 5.

7. Easy MIDI editor view focusing (= zoom and scroll) to item(s) activated for editing, or to visible item(s).

100. All the existing Reaper features and workflows should exist also after above requirements have been implemented.

There are many more requiremets that could be added to this list. But let's discuss this list of basic requirements first.
Is there something essential missing?
Do you see some problems already in this basic list?

jnif
jnif is offline   Reply With Quote
Old 11-23-2012, 10:56 AM   #77
Lawrence
Human being with feelings
 
Join Date: Mar 2007
Posts: 21,497
Default

That ^^^ seems to pretty much accurately detail what I always understood to be the changes asked for that would generally bring Reaper's basic midi editing up to the level of some others in those particular areas.

Yes, that seems accurate (to me anyway, mmv) Jnif.

P.S. I don't know about the addendum to #1 though, which (maybe?) actually should include dialog functions and similar, if there are notes which are actually selected across multiple items for quantize, transpose, whatever. If you select notes across items and call... a "Humanize" dialog, shouldn't all those notes get humanized? If you run a script on midi notes, shouldn't all the selected notes (across multiple items and/or tracks inside the editor) be affected?
Lawrence is offline   Reply With Quote
Old 11-23-2012, 11:12 AM   #78
jnif
Human being with feelings
 
jnif's Avatar
 
Join Date: Dec 2008
Posts: 2,042
Default

Quote:
Originally Posted by Lawrence View Post
P.S. I don't know about the addendum to #1 though, which (maybe?) actually should include dialog functions and similar, if there are notes which are actually selected across multiple items for quantize, transpose, whatever. If you select notes across items and call... a "Humanize" dialog, shouldn't all those notes get humanized? If you run a script on midi notes, shouldn't all the selected notes (across multiple items and/or tracks inside the editor) be affected?
Yes of course. I added the addendum only to make it clear we need interactive (like drag-and-drop with mouse) multi-item editing capability directly in the PRV. And any kind of (possibly already existing) script or batch method of editing (somehow) selected notes in multiple items at the same time is not enough. We need direct selecting and editing of events usign mouse cursor.

We can add a separate requirement that includes transpose/quantize/humanize/etc of selected events across multiple items.

jnif

Last edited by jnif; 11-23-2012 at 11:28 AM.
jnif is offline   Reply With Quote
Old 11-23-2012, 11:28 AM   #79
gofer
-blänk-
 
gofer's Avatar
 
Join Date: Jun 2008
Posts: 11,159
Default

I feel misunderstood. I didn't ask for more examples of why people want it. I want it myself and I know why.. IMO it is a given that Reaper's item-centric approach (which is the term I'm afraid I coined myself back when the inline editor got built and that evolved into item-based vs track-based - I feel guilty about it but nothing I tried to get rid of these terms ever worked) has to be loosened up.
I admit, I got pretty much carried away by the course this thread took at the time of my last reply and probably buried a bit too deep what I actually asked for. Sorry for that. Probably I should have just ignored the banter and asked straight away:

What I am after is practical solutions to ambiguous situations where multiple items - or none at all - are where the user creates new events.

When you copy+drag events in the piano roll to a space outside their original item's borders and there are multiple items existing on that track at the place where you drop them - what should happen?
gofer is offline   Reply With Quote
Old 11-23-2012, 11:28 AM   #80
Lawrence
Human being with feelings
 
Join Date: Mar 2007
Posts: 21,497
Default

Yeah. I agree.

In my mind, and of course my personal thinking isn't the model or standard for anything for anyone else, it's just one subjective opinion among millions ..., selection editing in general is a pretty widely universal "assumption".

That whatever is physically selected will always be affected by a function or action or script, in any and all cases related to editing from midi to audio to automation or just about anything else. Physical selection always (or rather, maybe should) define the action target(s).

I always assume that's the case for any software, any class of software that edits things, and it's almost true.
Lawrence 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 07:03 PM.


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