Old 12-05-2009, 05:04 PM   #81
wotnik
Human being with feelings
 
Join Date: Dec 2008
Posts: 2
Default Tux Guitar as plug-in

Hi, I'm absolutely not a "techy" so this may be complete bo**ocks - could some function from something like tux guitar be used as a plug-in for score editing?
wotnik is offline   Reply With Quote
Old 12-05-2009, 05:46 PM   #82
Hartley Mays
Human being with feelings
 
Join Date: Sep 2009
Location: Cincinnati, Ohio
Posts: 307
Default Tux Guitar

I've downloaded TuxGuitar (not the most recent release) and player around a little with it, but I've never tried to do any development on it, nor had any contact with the authors.

It's java based, so the same pros and cons of java vs. C++ discussed in this thread apply.

My own thought is to continue pursuing Frinika as the java alternative and exploring C++-based alternatives, but if anyone wants to see if there are significant advantages to TuxGuitar's notation editor over Frinika's, we could reconsider.

Hartley
Hartley Mays is offline   Reply With Quote
Old 12-05-2009, 06:03 PM   #83
LCipher
Human being with feelings
 
LCipher's Avatar
 
Join Date: Apr 2008
Posts: 2,036
Default

Im not exactly sure of the functionality that we are talking here, but has anyone looked at Muscore???

http://www.musescore.org/en


Sourcefiles are available, its very stable, ongoing development.




It's not just a viewer either - its editable.

If there was some <<<---->>> midi transfer in REAPER / MUSECORE that could be established (kinda like a wave editor program in REAPER now, but with the ability to select tracks, and maybe store the muscore metadata), then wouldnt that work?
LCipher is offline   Reply With Quote
Old 12-06-2009, 01:06 AM   #84
Xenakios
Human being with feelings
 
Xenakios's Avatar
 
Join Date: Feb 2007
Location: Oulu, Finland
Posts: 8,062
Default

Quote:
Originally Posted by LCipher View Post
Im not exactly sure of the functionality that we are talking here, but has anyone looked at Muscore???

http://www.musescore.org/en


Sourcefiles are available, its very stable, ongoing development.
Source code licensed under GPL so using that app would need to happen without changing or using it's source code directly. (Unless it happened the authors gave the permission to make it interoperate with evil non-Free software like Reaper...)
__________________
I am no longer part of the REAPER community. Please don't contact me with any REAPER-related issues.
Xenakios is offline   Reply With Quote
Old 12-06-2009, 11:21 AM   #85
MikeLacey
Human being with feelings
 
Join Date: Dec 2006
Location: UK
Posts: 789
Default

@Hartley

If the Java Score Editor is set-up as the external editor it won't be able to talk to REAPER, nothing in REAPER will be waiting for a request for data. I think something (a C++ extension) needs to be set-up to handle communications with the Java Score Editor (the JSE). A C++ extension will be able to get at the note data for a particular item directly from REAPER (via GetSetItemState() I think) and not rely on the .rpp file being up to date.

This approach also means that the translation of REAPER note data to MIDI and back again could be handled separately, reducing the amount of work being done in the JSE.

I think the sequence of events might go something like this. (Extension is the C++ Extension)
  1. User fires off the Extension
  2. The Extension creates a socket and begins listening for a JSE on that socket
  3. The Extension launches a JSE
  4. The JSE makes contact with the Extension and requests data
  5. The Extension gives the JSE the data
  6. Using the JSE the user creates a masterpiece
  7. The user tells the JSE to save and close
  8. The JSE gives the modified data back to the Extension
  9. The Extension gives the data back to REAPER and tells the JSE it's ok to shut down
  10. The JSE shuts down
  11. The Extension hands control back to REAPER
I've written sockets programs in a UNIX environment (a proper environment just so you know) and the thing that immediately occurs to me is that step 2 above is a bit simplified. It should read more like The Extension will have to do something like create a new thread which will create a socket and begin listening for a JSE on that socket - leaving the main thread of the Extension free to continue with step 3.

Jeffos is the person to advise on this though as he's the person who's done some socket stuff in REAPER.

Have you had a think about what format you'd like to receive data from REAPER?

You seem to have made some quite stunning progress by the way

Mike
__________________
Mike Lacey, Leicestershire, UK
MikeLacey is offline   Reply With Quote
Old 12-06-2009, 11:26 AM   #86
MikeLacey
Human being with feelings
 
Join Date: Dec 2006
Location: UK
Posts: 789
Default

@Hartley
Quote:
Originally Posted by Hartley
I guess the easiest way to make it available will be to attach it to the forum post. Are there any size restrictions on that?
Hmm dunno, how big is it?
__________________
Mike Lacey, Leicestershire, UK
MikeLacey is offline   Reply With Quote
Old 12-06-2009, 12:02 PM   #87
MikeLacey
Human being with feelings
 
Join Date: Dec 2006
Location: UK
Posts: 789
Default

Quote:
Originally Posted by Hartley
My own thought is to continue pursuing Frinika as the java alternative and exploring C++-based alternatives
I agree.
__________________
Mike Lacey, Leicestershire, UK
MikeLacey is offline   Reply With Quote
Old 12-06-2009, 12:17 PM   #88
Hartley Mays
Human being with feelings
 
Join Date: Sep 2009
Location: Cincinnati, Ohio
Posts: 307
Default launching, size

Mike,

My post about the launching may have been confusing. I agree completely about the need for the C++ extension to Reaper to do socket communication with Frinika so that full functionality of an embedded editor can be simulated. I was just referring to how Frinika would get launched initially; everything after that can definitely be through the socket communication.

I was also discussing my plan to get Frinika available ASAP before all the socket stuff is available to test out its score editor more. Maybe the two different topics got muddled.

With regard to the full implementation, I think that probably either approach for launching would work fine. Under mine, your step 3 would be eliminated because Frinika would be launched by the current external editor mechanism, which could also fire off the extension. But I'm not familiar at all with how the extension itself will be wired into the base product, so maybe that's problematical?

Anyway, Frinika does not currently expect/accept any run time arguments, so I'm taking advantage of that to set up the "Reaper path" in the code. This would theoretically allow integration of my Reaper code into the base Frinika product without changing any of its startup for regular use, nor exposing the presence of the reaper hooks in the documented configuration options. So once it's launched from Reaper, it can set up its socket and begin to listen just as you've outlined. If it's going to get launched by the Extension, then we need to either figure out another way for it to detect that it's running from Reaper, or give up on maintaining complete compatibility with the Frinika base code.

The size of the combined Frinika jar and .exe stub are somehwat over 2m.

Later,
Hartley
Hartley Mays is offline   Reply With Quote
Old 12-06-2009, 12:42 PM   #89
MikeLacey
Human being with feelings
 
Join Date: Dec 2006
Location: UK
Posts: 789
Default

Hey Hartley,

Quote:
Under mine, your step 3 would be eliminated because Frinika would be launched by the current external editor mechanism, which could also fire off the extension.
Hmmm, dunno. I'm not convinced ... Xen? Jeffos?

Quote:
Frinika does not currently expect/accept any run time arguments, so I'm taking advantage of that to set up the "Reaper path" in the code. This ... allow integration of my Reaper code into the base Frinika product without changing any of its startup
It didn't occurr to me that you could make these changes and maintain compatibility with the existing code. Nice one.

Quote:
we need to either figure out another way for it to detect that it's running from Reaper, or give up on maintaining complete compatibility
Yes, later though, I'll put in on the to-do list.
__________________
Mike Lacey, Leicestershire, UK
MikeLacey is offline   Reply With Quote
Old 12-06-2009, 12:51 PM   #90
EvilDragon
Human being with feelings
 
EvilDragon's Avatar
 
Join Date: Jun 2009
Location: Croatia
Posts: 24,790
Default

2 MB for a score editor? That seems a bit much. Wait... would this launch Frinika with all its bells and whistles, but focus it to score editor only?

Wouldn't a better choice be just strip the score editing part of Frinika to a much smaller executable and use that instead?
EvilDragon is offline   Reply With Quote
Old 12-06-2009, 01:32 PM   #91
NAS
Human being with feelings
 
NAS's Avatar
 
Join Date: Dec 2007
Location: In church, burning it down
Posts: 1,345
Default

Yeah i think the idea is to just add to the standard Frinika so that when it gets updated it is usable still
Rather than rip out the scoring alone and then have to rebuild everytime Frinika gets updated

Then again i may be talking crap

NAS
__________________
Not Gods or Saints but HUMAN be
NAS is offline   Reply With Quote
Old 12-06-2009, 01:35 PM   #92
MikeLacey
Human being with feelings
 
Join Date: Dec 2006
Location: UK
Posts: 789
Default

Hartley - could you check your PMs please?

Mike
__________________
Mike Lacey, Leicestershire, UK
MikeLacey is offline   Reply With Quote
Old 12-06-2009, 01:51 PM   #93
EvilDragon
Human being with feelings
 
EvilDragon's Avatar
 
Join Date: Jun 2009
Location: Croatia
Posts: 24,790
Default

Quote:
Originally Posted by NAS View Post
Yeah i think the idea is to just add to the standard Frinika so that when it gets updated it is usable still
Rather than rip out the scoring alone and then have to rebuild everytime Frinika gets updated

Then again i may be talking crap

NAS
It might be better to rip out the score editing part, just to get smaller executable. If they do it right, the updates won't be necessary, maybe only for adding features. Or something. :=)
EvilDragon is offline   Reply With Quote
Old 12-06-2009, 08:47 PM   #94
Hartley Mays
Human being with feelings
 
Join Date: Sep 2009
Location: Cincinnati, Ohio
Posts: 307
Default status, jar size

Fairly good progress and one unexpected glitch to report. When called from Reaper via the external editor option, Frinika now opens a dummy project previously saved to use as the framework to import the midi files. When it's opened normally, it proceeds with its startup options about opening a new or existing project. The glitch I've hit is that Frinika is expecting at least one tempo event in the import, or it throws an exception. I need to figure out how to handle that; not clear if we can just bypass it for Reaper's purposes. I had to add some code to Frinika so that the "console" messages (stdout for C++, System.out.println for java) get routed to an external log file. It seems to me that would be a good enhancement to the base Frinika product, I'll check with the developers about it.

With regard to the concern about the size of the executable jar, I think that's an issue we can get to later in the process, once it's certain that we'll go forward with Frinika. I haven't looked into how much of the 2M is devoted to core functionality that we need in order to use the score editor, vs. how much is for unrelated things like the embedded synths that it has, etc. It also relates to the issue of whether we maintain full compatibility with the product with the Reaper changes integrated into the base (my preference), or essentially fork a separate version. If we do maintain the compatability and integration, there may be a way at build time to eliminate portions that we don't need.

Later,
Hartley
Hartley Mays is offline   Reply With Quote
Old 12-06-2009, 08:58 PM   #95
MikeLacey
Human being with feelings
 
Join Date: Dec 2006
Location: UK
Posts: 789
Default

Quote:
Originally Posted by Hartley
... size of the executable jar, I think that's an issue we can get to later in the process ...
Yes, that's the right way round. Make it work, then make it work fast (enough)
__________________
Mike Lacey, Leicestershire, UK
MikeLacey is offline   Reply With Quote
Old 12-07-2009, 04:28 AM   #96
Geoff Waddington
Human being with feelings
 
Geoff Waddington's Avatar
 
Join Date: Mar 2009
Location: Dartmouth, Nova Scotia
Posts: 11,183
Default

Quote:
Originally Posted by Hartley Mays
With regard to the concern about the size of the executable jar, I think that's an issue we can get to later in the process...
IMHO, although I certainly appreciate the Reaper "lack of bloat" philosophy, 2 meg could hardly be considered a large app by today's standards, especially when weighed against the cost of maintaining separate branches.


just my 2c.
Geoff Waddington is offline   Reply With Quote
Old 12-07-2009, 04:32 AM   #97
EvilDragon
Human being with feelings
 
EvilDragon's Avatar
 
Join Date: Jun 2009
Location: Croatia
Posts: 24,790
Default

May be so, but compare Reaper's size and what it offers, and this executable's size and what it offers. Half of Reaper's install executable for just one function (score view/edit)? Seems awfully overwhelming for just that. IMHO
EvilDragon is offline   Reply With Quote
Old 12-07-2009, 06:16 AM   #98
DaveG
Human being with feelings
 
DaveG's Avatar
 
Join Date: Jun 2009
Location: Canada
Posts: 320
Default

Quote:
Originally Posted by EvilDragon View Post
May be so, but compare Reaper's size and what it offers, and this executable's size and what it offers. Half of Reaper's install executable for just one function (score view/edit)? Seems awfully overwhelming for just that. IMHO
Same sort of deal when using a external audio editor with a large foot print, no big deal the ability to have a score editor would be great no matter what size the app is (of course smaller is always better).
DaveG is offline   Reply With Quote
Old 12-07-2009, 07:32 AM   #99
Soffej
Human being with feelings
 
Join Date: Dec 2009
Posts: 3
Default

OK, guys..
I understand why Jeffos mysteriously disappear from this thread...
I'm also used to these forums but I prefer post the following stuff in an anonymous way:
- Making a java app discuss with Reaper could be considered as a SUPER MEGA TRICKERY (I hope *** won't see this stuff!!), C++ should be the way to go.
- I coded that LIKE A PIG: this is a simple/incomplete Proof Of Concept (POC). It was just made to check if it was possible and to check how reaper was reacting (while doing its normal job: record, play, ..)
=> I saw that it worked but I stopped there (such "trickeries" are not my style ;-) but it should get you started

So, here's attached an example showing how to make a Java application discuss with REAPER through sockets:
- reaper_reaServer_POC++.zip: c++ project (server side)
- reaper_reaServer.dll.zip: a win32 build of this project
- reaClient.java.zip: java implementation (client side)

Discussion example:
Code:
Opening connection to localhost port 23
About to start reading/writing to/from socket.
======> SENDING: 5µ0µ0µ
======> RECIEVED: <TRACK
NAME ""
PEAKCOL 16576
BEAT -1
AUTOMODE 0
VOLPAN 1.00000000000000 0.00000000000000 -1.00000000000000
MUTESOLO 0 0
IPHASE 0
ISBUS 0 0
BUSCOMP 0
SHOWINMIX 1 0.666700 0.500000 1 0.500000
FREEMODE 0
REC 0 0 0 0 0 0
TRACKHEIGHT 0 0
INQ 0 0 0 0.5000000000 100 0 0 100
NCHAN 2
FX 1
TRACKID {74CFAD9E-425F-4DA8-8D59-5BF76AE7BF32}
PERF 0
MIDIOUT -1
MAINSEND 1
>
In that example the java client says "5µ0µ0µ" which means "call GetSetObjectState() for track 1, simple get (i.e. nothing to set)" the server C++ extensions replies with the related chunk...
Attached Files
File Type: zip reaper_reaServer_POC++.zip (13.1 KB, 199 views)
File Type: zip reaper_reaServer.dll.zip (4.8 KB, 210 views)
File Type: zip reaClient.java.zip (1.7 KB, 235 views)
Soffej is offline   Reply With Quote
Old 12-07-2009, 08:25 AM   #100
MikeLacey
Human being with feelings
 
Join Date: Dec 2006
Location: UK
Posts: 789
Default

Quote:
Originally Posted by EvilDragon View Post
May be so, but compare Reaper's size and what it offers, and this executable's size and what it offers. Half of Reaper's install executable for just one function (score view/edit)? Seems awfully overwhelming for just that. IMHO
Well ... it won't be mandatory to use it. But do feel free to write somethng a bit smaller
__________________
Mike Lacey, Leicestershire, UK
MikeLacey is offline   Reply With Quote
Old 12-07-2009, 08:28 AM   #101
MikeLacey
Human being with feelings
 
Join Date: Dec 2006
Location: UK
Posts: 789
Default

Nice one Soffej thanks, a good starting point.

I have to ask though, what does "5µ0µ0µ" mean?
__________________
Mike Lacey, Leicestershire, UK
MikeLacey is offline   Reply With Quote
Old 12-07-2009, 08:49 AM   #102
Soffej
Human being with feelings
 
Join Date: Dec 2009
Posts: 3
Default

ha ha!!

Quote:
Originally Posted by MikeLacey View Post
I have to ask though, what does "5µ0µ0µ" mean?
This is what I call a "pig" implementation:
- µ: separator
- first token (here "5"): identifies the API function to be called (see the server code, only a few functions were implemented in that poc!)
- then: the parameters (the number of params depends of the called function of course)
so here:
- 0: track number (as we can not pass pointers such as MediatTrack*, note: track n° is 0-based in the current implementations)
- 0: just says that we want to use GetSetObjectState() as a getter not as a setter
Soffej is offline   Reply With Quote
Old 12-07-2009, 10:50 AM   #103
MikeLacey
Human being with feelings
 
Join Date: Dec 2006
Location: UK
Posts: 789
Default

Ah... Ok, I got you. Thx Soff

Mike
__________________
Mike Lacey, Leicestershire, UK
MikeLacey is offline   Reply With Quote
Old 12-09-2009, 06:14 AM   #104
Jeffos
Mortal
 
Jeffos's Avatar
 
Join Date: Dec 2008
Location: France
Posts: 1,969
Default

I've seen elsewhere that this POC was "exactly what you needed"..
So a last post here to say that I had a look on the code: sure, it can get you started but it's indeed coded "LIKE A PIG" (leaks, hardcoded sizings, no proper thread ending, some interesting parts are commented, working with sockets normally implies error management, timeouts, etc..): this part should be re-worked. However, this very *bad* idea should allow remote control of Reaper (LAN) and hooking any app made in any language without adding a 3rd worse techno (such as Corba).

About the "straight to the point" REAPER extension plugin approach: I understand a bit late that what frightens some people is C++. I'm sorry if I appeared a bit "blind" about that (note for myself: jeff! what is not an issue for you may be one for others!!). Xenakios already encouraged you in a better day than I can do it. Here, for eg, when I compare the time I need to make a dropdown in java and in C (w/o resource editor moreover!) I would sometimes tend to agree.. but nooo! So many advantages...
So my final advice for this ambitious project would be: "take your time" and before java, "just give the standard REAPER extension plugin approach a try" !
Jeffos is offline   Reply With Quote
Old 12-09-2009, 06:47 AM   #105
MikeLacey
Human being with feelings
 
Join Date: Dec 2006
Location: UK
Posts: 789
Default

Hey Jeff,

You're quite right regarding the Proof Of Concept code kindly supplied by Soffej. It lacks a number of things - but it is a good starting point.

I can see from the code that Soff had in mind a very flexible system as a final destination - but this one will be limited to reading and writing MIDI data from and to the .rpp using GetSetTrackState(). I'm sorry that you think it's a bad idea... I can see that C++ is a better choice in some ways for coding a score editor but we've not been able to find a C++ application whose authors are willing to let use integrate into "unfree" software. And Frinika does seems well thought of, let's see how we do.

One advantage to this approach is that, once the C++ REAPER side is completed, it could easily be modified to call any editor. If another editor did make an appearance it would be possible to trial it without too much trouble.

Regards,

Mike
__________________
Mike Lacey, Leicestershire, UK
MikeLacey is offline   Reply With Quote
Old 12-09-2009, 07:34 AM   #106
Geoff Waddington
Human being with feelings
 
Geoff Waddington's Avatar
 
Join Date: Mar 2009
Location: Dartmouth, Nova Scotia
Posts: 11,183
Default

Quote:
Originally Posted by Jeffos
So my final advice for this ambitious project would be: "take your time" and before java, "just give the standard REAPER extension plugin approach a try" !
I understand this position well as I am wrestling with this exact issue myself.

From an earlier post in this thread:

Quote:
Originally Posted by Geoff Waddington
I've succesfully built a proof of concept app in C# using .NET that allows bidirectional communication with Reaper using the C++ SDK
I think it boils down to overall project approach fundamentals.

I wasn't sure what I was attempting was even feasible, so using a language (C# in this case) where I could use VS to do the GUI, didn't have to worry about memory management, etc. was a plus.

This was the R&D / risk management step in the total project timeline.

Now that the POC is complete I am faced with porting the whole thing to C++ in order to have tighter Reaper integration, OSX support, and perhaps even more importantly, allow easy growth as Reaper itself grows.

I believe this was the correct approach for this particular project.

I see a lot of parallels with what you folks are attempting.

I must heartily agree with Jeffos though, that you will likely end up in C++ eventually .

Quote:
Originally Posted by MikeLacey
One advantage to this approach is that, once the C++ REAPER side is completed, it could easily be modified to call any editor. If another editor did make an appearance it would be possible to trial it without too much trouble
This holds true as long as the approach and mechanisms (reading writing .RPP files, etc.) remains the same.

I found with my project that some of the communication was more easily accomplished differently once C++ direct calls were available.

my .02c -- hopefully adding perspective not confusion
Geoff Waddington is offline   Reply With Quote
Old 12-11-2009, 08:12 AM   #107
liteon
Human being with feelings
 
liteon's Avatar
 
Join Date: Apr 2008
Posts: 510
Default

an author of a software piece (e.g: notation editor), can re-release it under any license for a specific purpose afaik and if such an author is a reaper fan, things might be even easier :-). but there is no need to beg people, as it isn't rocket science looking at it from any angle.

haven't read the entire discussion:
but, on the c++ vs java bit, from personal experience i find that java can be quite slow for heavier processes, thus eventually limiting the userbase only to the higher benchmark crew. :-(
if its possible to do it solely in c++ as an extension, then thats the way to go imo.

Last edited by liteon; 12-11-2009 at 10:38 AM. Reason: typos
liteon is offline   Reply With Quote
Old 12-16-2009, 12:21 PM   #108
Malevol3nt
Human being with feelings
 
Join Date: Sep 2009
Posts: 107
Default

Wow. Java, socket programming, what's going on here?

Why exactly is C++/Java and all that socket programming necessary to implement a score editor? I mean, all you would really need is an extension linked to a hotkey, then when you have a MIDI track selected you hit the hotkey, the extension catches all the MIDI data on that track and displays it in it's own Score editor (that you can then edit).

Or am I missing something?
Malevol3nt is offline   Reply With Quote
Old 12-16-2009, 12:52 PM   #109
MikeLacey
Human being with feelings
 
Join Date: Dec 2006
Location: UK
Posts: 789
Default

"all you would really need is an extension linked to a hotkey"

Sounds good Go on then

Seriously though, the answer is that no-one fancies writing a score editor from scratch and that we have a Java person (Hartley) who already has some experience with an app which has a score editor (Frinika). Whatever works, in other words.

Mike
__________________
Mike Lacey, Leicestershire, UK
MikeLacey is offline   Reply With Quote
Old 12-16-2009, 01:04 PM   #110
Malevol3nt
Human being with feelings
 
Join Date: Sep 2009
Posts: 107
Default

Quote:
Originally Posted by MikeLacey View Post
"all you would really need is an extension linked to a hotkey"

Sounds good Go on then

Seriously though, the answer is that no-one fancies writing a score editor from scratch and that we have a Java person (Hartley) who already has some experience with an app which has a score editor (Frinika). Whatever works, in other words.

Mike
Ah, okie. Well I'm too busy with this Automation extension I'm working on right now to do anything else. + I'm not familiar with score editors all that much. If I make good progress with my own extensions I might try to tackle other parts of Reaper, but no promises.
Malevol3nt is offline   Reply With Quote
Old 12-16-2009, 01:39 PM   #111
MikeLacey
Human being with feelings
 
Join Date: Dec 2006
Location: UK
Posts: 789
Default

Cool....

Can I be nosy and ask what you're working on?
__________________
Mike Lacey, Leicestershire, UK
MikeLacey is offline   Reply With Quote
Old 12-29-2009, 10:01 AM   #112
Malevol3nt
Human being with feelings
 
Join Date: Sep 2009
Posts: 107
Default

Here's a nice page I happened to bump into:

http://wiki.python.org/moin/PythonInMusic

Look under the "Music Notation" section.
Malevol3nt is offline   Reply With Quote
Old 12-29-2009, 01:22 PM   #113
MikeLacey
Human being with feelings
 
Join Date: Dec 2006
Location: UK
Posts: 789
Default

Just to give everyone an update:

Hartley's been very productively hacking away and should have a version of Frinika to demo as a REAPER external MIDI editor soon.

I've been hacking no less furiously but much less productively at the sockets code and should have something to demo at some point...
__________________
Mike Lacey, Leicestershire, UK
MikeLacey is offline   Reply With Quote
Old 01-12-2010, 07:17 AM   #114
Geoff Waddington
Human being with feelings
 
Geoff Waddington's Avatar
 
Join Date: Mar 2009
Location: Dartmouth, Nova Scotia
Posts: 11,183
Default

Just a quick retraction of a couple of previous posts.

There is remaining, of course, the OSX question.

Aside from that I'm actually quite pleased and surprised at how things are coming along using C# to talk to / from Reaper's C++ CSurf DLL for my project.

So please take my earlier, really quite adamant position about having to eventually port the score editor to C++ with the required grain(s) of salt
Geoff Waddington is offline   Reply With Quote
Old 02-05-2010, 06:06 PM   #115
musicbynumbers
Human being with feelings
 
musicbynumbers's Avatar
 
Join Date: Jun 2009
Location: South, UK
Posts: 14,214
Default

keeping my eye on this thread, sounds really cool!

hope it's still looking likely?
musicbynumbers is offline   Reply With Quote
Old 02-05-2010, 06:35 PM   #116
Hartley Mays
Human being with feelings
 
Join Date: Sep 2009
Location: Cincinnati, Ohio
Posts: 307
Default work in progress

Yes, work is progressing, albeit slowly.

A prototype using Frinika basically worked, but there are some real basic problems with the Frinika notation editor, mainly that key signatures are not supported. So we're currently trying TuxGuitar, which was mentioned earlier in this thread, at the top of page 3. It supports key signatures, and has some other features that may be of interest to Guitar players.

Here's the website for it:

http://tuxguitar.herac.com.ar/


Actually, I happened to notice this post to the thread when I brought up Reaper to test the TuxGuitar communication, got the message about 3.22 being available, installed it, then took a quick look at the forums as an excuse for another beer.

Later,
Hartley
Hartley Mays is offline   Reply With Quote
Old 02-06-2010, 09:36 PM   #117
sebas777
Human being with feelings
 
sebas777's Avatar
 
Join Date: Nov 2006
Posts: 2,182
Default

@ LCipher: I'm also +100 votes on the MuseScore <-> Reaper integration. It is a quite powerful score editor, and it's got a strong user base (I remember writing a few posts on their forum, immediately replied by the developers).

Actually even a simple solution that could be used as an additional lane in the piano-roll or in-place in the Arrange window, would be welcome in Reaper.



Then: ...JS plugins to interpret the score. I believe that the interpreting plugins will be the VSTi's of the XXI century.
sebas777 is offline   Reply With Quote
Old 02-07-2010, 04:28 AM   #118
musicbynumbers
Human being with feelings
 
musicbynumbers's Avatar
 
Join Date: Jun 2009
Location: South, UK
Posts: 14,214
Default

Thanks for the reply

I'm just excited that it might eventually be wittled down to a single install process. That would be great. No rush though.. Just thankful someone out there is working for the greater good!
musicbynumbers is offline   Reply With Quote
Old 02-07-2010, 07:13 AM   #119
ajaym
Human being with feelings
 
Join Date: Aug 2009
Posts: 210
Default

Wow!. This is definitely something I would kill for. Putting in my 10c worth (as a systems architect and the BCR2000 plugin author), I think running the score editor out of process seems like a very sensible idea. Indeed, this is exactly how my BCR2000 visual console UI works. In that case I used COM to very quickly send information to the console as an out-of-process COM server, and the server console code then immediately returns, posting itself an asynchronous callback; thus, no cross-process blocking. This has the advantage of being a natural idiom in C++, and you can efficiently marshal arrays of data quite quickly; I used BSTRs for string data, otherwise for numeric data COM will marshal that directly. Then I just plunk everything into a SAFEARRAY. At the VB end, the array is directly readable. This means that the server can very very quickly marshal it out into local storage and then acknowledge the call. This works very well with both Reaper and Sonar, I haven't had any glitches or issues streaming large complex projects with the control surface plugin enabled.

And all sorts of horrid UI threading issues just go away in this environment.

I also bypassed all the COM plumbing that things like ATL provide and called the underlying C calls directly. It's not well known but if you want to build your own COM data structures in C, you can call a COM server easily in pure C, which is what I have done here for maximum efficiency.

I appreciate that COM isn't as attractive if you are calling into a Java client. However in that case (I'll come back to the sockets/named pipes/shared memory IPC alternatives in a moment), having a C DLL which does the IPC using COM, and is called by the Java code using JNI, isn't necessarily a bad solution. It doesn't matter if the Java client is slow to translate and re-marshal the data, because it will return control immediately and call itself back to do the slow stuff in a worker thread. This leaves Reaper completely unblocked and avoids any audio engine issues.

Of course you could also use e.g sockets, or named pipes (probably a slightly more efficient option under Windows), or even - and I think this probably has the most merit for this application, blocks of shared memory. This allows you to marshal a vast amount of information between processes very efficiently. To notify the called process, post a good old-fashioned window message, you can simply reserve an mutually agreed message identifier, the Windows API has RegisterMessage for that. By posting to the message queue on the receiving server process you avoid any awkward blocking issues on the Reaper side. Frinika's got to have a top-level window and a message queue pump anyway, so you can just post to that.

This is as lightweight, probably, as you would get for cross-process IPC, and you can use a mutex for synchronisation. The called process can be quite inefficient, because it will run scheduled entirely independently of Reaper, and issues like Java garbage collection simply won't arise. (in my case, the out of proc server is a VB6 program, because the runtime is always available and I didn't want users to have to download a large JVM etc, but in this case, we already have the codebase in Java, so stick with it.)

The called process probably should simply copy that block of shared memory immediately it receives the posted message from Reaper, and post back an acknowledgement message. This is kind of like the old-fashioned DDE (dynamic data exchange) protocol in Windows, which, by the way, is very efficient, despite being not very sexy by today's standards. Recall that the early Windows techniques had to run on very low-end hardware and they are still valid in this kind of 'performance-optimised' environment.

So now you can have quite intensive interaction with the score editor and in due course it will notify Reaper of the changes made to the track. A 'shim' layer between the score editor and Reaper should run in the server process - a DLL springs to mind, called by JNI. It matters not how inefficient this is because IT WILL ONLY CAUSE A DELAY inside the score editor before Reaper gets the updates. The shim takes the internal structures of Frinika, and maps them into some kind of format that Reaper can very quickly bulk load back into a track. Then it places this information in a block of shared memory and posts a message back to Reaper, which in its own sweet time, picks up the notification and applies the track event list updates to the selected track(s). I can also imagine using a queue of shared memory blocks so that mutex contention issues are largely avoided; Frinika sets up a block of data, calls back to Reaper and then takes a new block off a circular list large enough to avoid contention issues. This allows a substantial lag between the two processes, you could then be going back and making a whole bunch more changes to the score in Frinika, which is then busily, in the background, building new event list blocks for Reaper, but if Reaper's too busy, it can just ignore them until at some point things quiesce. Of course, you want a two-way flow of information. But in the 'I'm playing my project' mode, you aren't editing Reaper event lists. (you want Frinika to display the score dynamically, of course, but that's cheap). If you go back to Reaper, and do some MIDI editing, then it'll be quiesced anyway, so you won't have a real-time response problem back to Frinika, Reaper can immediately send the event list changes as you go, the overhead won't matter.

I can see that you could use a UDP datagram over a socket instead of a Windows message, but you are marshalling a lot more data per notification if you do that. A Windows message is an incredibly lightweight IPC mechanism, albeit Windows-specific, you'd have to map this on a Mac, I appreciate.

Anyway, I must go have a look at Frinika. As a refugee from Sonar, the one thing I really miss is the score editor, which I really do need. I don't think it makes sense to integrate score editing with Reaper directly, it makes a lot more sense to provide a framework for external plugins to interact with Reaper's internal track event lists in real time. As such, a generalised framework would enable this project, and all sorts of other interesting initiatives, to move forward without bloating Reaper. However it would involve probably some new APIs optimised for moving large amounts of track events to and from Reaper.
ajaym is offline   Reply With Quote
Old 02-07-2010, 11:15 AM   #120
Hartley Mays
Human being with feelings
 
Join Date: Sep 2009
Location: Cincinnati, Ohio
Posts: 307
Default TuxGuitar progress

Ajaym,

You should take a look at TuxGuitar rather than Frinika, as I mentioned in my Friday post above. The website is in that post.

Thanks for the advice about the alternatives for the interaction. We'll be back to work on that shortly I think (haven't heard from Mike Lacey for a while). I got the export logic working today to send data back from TuxGuitar, after getting the import working Friday. So I think we will be able to make it generally available within the next few days after some more testing and cleanup.

Later,
Hartley
Hartley Mays 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 11:22 AM.


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