Improving JACK MIDI Out

classic Classic list List threaded Threaded
27 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Improving JACK MIDI Out

igevorse
Hello all!

I am improving JACK support in MuseScore, and I want to duscuss some ideas.

I've looked throught the forum/issues - people want to use VST(i) with MuseScore and they have problems and difficulties with it. They want to have separate channels or ports per staffs (for example: [0],[1],[2],[3], etc.)

It was the problem for years, and now I can solve it, I just need your advice and permission (for changing UI, for example).

I've talked with daeavelwyn and he gave me an example of problem that he have.
Imagine if you have a score with staff1 = flute, staff2 = piano and staff3 = piano. MuseScore makes it: channel1 = flute, channel2 = piano.
Now you decided to add clarinet. Clarinet staff would be between flute and piano, so we will get channel1 = flute, channel2 = clarinet and channel3 = piano.
But... you use an external VSTi, and without changing settings in qmidiroute clarinet is playing like piano!
So, every time you writing a new score you need to re-route qmidiroute.

2 possible solutions:

1. We need to route signals once and change staff's channel in MuseScore!
We should have an ability to change channels in mixer window.
But not all users use JACK MIDI, right? So, We need to hide this feature from regular users, and show only if Preferences->I/O->"Use JACK MIDI" checkbox is checked.

It would be like that: [4]
Also, we need to slightly change MuseScore file format to have an ability to save our staff->channels links.

Recap: We need to change mixer GUI and file format.
We get an ability to set channels to staffs.

2. One port per each staff

There is another approach, we wouldn't change GUI, and fileformat, and every staff would have an own port. Port names can be generated from staff name + number if name repeats.
You can see an example here: [5]

Which option is better?
Thank you.

[0] http://musescore.org/en/node/9813 march 2011
[1] http://musescore.org/en/node/10601 may 2011
[2] http://musescore.org/en/node/15565 march 2012
[3] http://musescore.org/en/node/16181 april 2012
[4] https://lut.im/mseD2xcj/TyALyJsp
[5] http://musescore.org/sites/musescore.org/files/issues/mscore-jack-midi-channel0-after01.png
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Improving JACK MIDI Out

David Bolton-2
On 5/29/2014 12:23 PM, igevorse wrote:

> I've talked with daeavelwyn and he gave me an example of problem that he
> have.
> Imagine if you have a score with staff1 = flute, staff2 = piano and staff3 =
> piano. MuseScore makes it: channel1 = flute, channel2 = piano.
> Now you decided to add clarinet. Clarinet staff would be between flute and
> piano, so we will get channel1 = flute, channel2 = clarinet and channel3 =
> piano.
> But... you use an external VSTi, and without changing settings in qmidiroute
> clarinet is playing like piano!
> So, every time you writing a new score you need to re-route qmidiroute.
In this instance the new clarinet staff should be assigned channel 3
rather than reordering all the channel numbers. This would require
saving the channel number to the MuseScore file as you mention in
solution 1 below.

> 2 possible solutions:
>
> 1. We need to route signals once and change staff's channel in MuseScore!
> We should have an ability to change channels in mixer window.
> But not all users use JACK MIDI, right? So, We need to hide this feature
> from regular users, and show only if Preferences->I/O->"Use JACK MIDI"
> checkbox is checked.
>
> It would be like that: [4]
> Also, we need to slightly change MuseScore file format to have an ability to
> save our staff->channels links.
>
> Recap: We need to change mixer GUI and file format.
> We get an ability to set channels to staffs.

This is the traditional method. Keep in mind that MIDI is limited to 16
channels per bank/port. So you would also need to save a bank number in
the file and display it in the UI in order to allow more than sixteen
instrument per score. (See "Finale instrument list.PNG" for a sample
screenshot)


> 2. One port per each staff
>
> There is another approach, we wouldn't change GUI, and fileformat, and every
> staff would have an own port. Port names can be generated from staff name +
> number if name repeats.
> You can see an example here: [5]
>
> Which option is better?
> Thank you.

This seems pretty clean. I don't have enough experience working with
external synths to know the disadvantages of option 2. Would all
synthesizers/samplers support this method? Are there limits to the
number of ports synthesizers/samplers might support?

If the user changed the staff name in the score would that trigger a new
automatic naming of the port and break the Jack audio connection for
that staff? If so, that would be unexpected (and undesirable) for the user.

David


------------------------------------------------------------------------------
Time is money. Stop wasting it! Get your web API in 5 minutes.
www.restlet.com/download
http://p.sf.net/sfu/restlet
_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Improving JACK MIDI Out

ChurchOrganist
In reply to this post by igevorse
First of all welcome aboard Maxim :)

I have a lot of experience working with MIDI as I used to program backing tracks to earn my daily bread at the turn of the century.

At the time I was using 4 XG modules and a Roland JV1010 to provide the means to render the tracks, 2 on internal sound cards and another 3 external modules connected on a 4 port external USB interface.

This was enough to render full orchestral backing tracks to a WAV file in one go using Cakewalk Sonar 3.

As David notes, the traditional method is to assign ports and channels to various sections of the score, and this is the way I would go personally.

If you start assigning MIDI ports to every stave you are going to run into limits imposed by the sound modules and/or OSs - for example there is a 10 device/port limit imposed by Windows XP.

I have been saying for some time that we need direct control over which channel MuseScore assigns to an instrument, and to me this is the way forward.

Before you jump in and start altering the mixer winder UI, be aware that there is a proposal to incorporate the mixer controls in the Instrument Selection dialogue, driven by the desire to be able to select Instrument and which sound from which soundfont from one interface rather than having to have two windows open.

It would make sense, therefore to have an extension to the Instrument selection window which gave direct control over MIDI port and channel, but which can remain hidden for users who don't need such level of control.

Here is a link to the discussion in Technology preview:-
http://musescore.org/en/node/24685 
This is in its infancy and needs a lot more work before it can be implemented - we're all far too busy trying to get MuseScore 2 released :) But once that has happened we can maybe work on it for the next release.

Incidentally - improving the JACK interface seems to me to be a good way forward to eventually providing VSTi support.

Regards
Michael
Regards
Michael
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Improving JACK MIDI Out

Maksim Grishin
Drawbacks of the second "One port per each staff" option

Actually we don't have any limitations from the OS for the number of ports per application. (I asked in #jack)

Correction:
There is a possible maximum number of ports in the system (in all applications in total), which can be defined when starting jackd.
Also, jackd2 can have a limit chosen at compile time (not sure).

Anyway, now I see the main problem:
Imagine that we have a score with 10 instruments. It looks and plays well.

1. You have 10 imaginary scores with 10 instruments in each score. If there is some conflicts, ports will be renamed. Also, I can not guarantee that application with 100 ports would work stable (can arise system lacks).
2. We can't save connections. Suppose we have two scores: one uses acoustic guitar sound, and one uses distorted guitar sound. This staves have the same name "Guitar". Also suppose we have 2 external synthesizers for acoustic and distorted sound. We'll open only one score in one moment.
Opening score one:
/******************
*Out ports: Guitar        
*
*Syn1: Acoustic
*Syn2: Distorted
*******************/             
Close it. Open the second. We'll get:
/******************
*Out ports: Guitar        
*
*Syn1: Acoustic
*Syn2: Distorted
*******************/

No difference? Yes. We don't have any information how to connect them. Even if staves have different names we don't know how to connect them. (Actually we can, but you need to keep the same name of staves in all your scores. As an ID. But it is a workaround, staff name is not for that.)

So, in each case we have a *connection problem*. But...stop. A connection problem was described in my first mail. And this "One port per each staff" approach was described as one of the possible solutions. We got the same problem.
Strike out it.

*Offtop*
It was an explanation for those who might be interested in this idea.
*/Offtop*

Now let's talk about assigning channels to staves:

1. It's commonly used in other notation or sound editing software. No need to learn something new.
2. We save an ability to connect ports automatically after opening score.
3. Different scores could use different names for parts (as should be).
4. It makes people hap..Well, that's enough.



Using mixer wasn't the best idea. Now we have to add 2 spinboxes: to change port and channel. Two new elements could be too much for this tiny window.
Using an instrument window is much better, I think. Also, this controls can be displayed only if "Use JACK MIDI" checkbox is checked.

Now interface could look like this:[0]

What do you think about it? Should I change something? Developers, I think I need your approval.



p.s.
Feel free to write about features related to JACK that you want to be implemented in MuseScore.
You can find me in #musescore as igevorse.

p.p.s
Sorry for the long letter :).

[0]: https://lut.im/se396lam/fEK9513X

------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Improving JACK MIDI Out

David Bolton-2

> Now interface could look like this: https://lut.im/se396lam/fEK9513X
>
> p.p.s
> Sorry for the long letter :).
>
>

Maksim,

First of all, thank you for the long letter! It was good of you to share
the findings of your research into this matter.

The screenshot looks like the right basic idea. I wouldn't expect to see
spin boxes on both the instrument line and the staff line--just one or
the other.

I would also expect it to eventually assign port and channel numbers
sequentially (rather than 3s all the way down), but I assume you were
just doing a quick mockup/prototype.

David


------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Improving JACK MIDI Out

lasconic
Administrator
Indeed, thanks for the long letter.

Internally, which object would be associated with a port/channel.
Instrument, Staff or Part?
Do you understand the difference between these 3 entities in the code?

lasconic





2014-06-06 4:33 GMT+02:00 David Bolton <[hidden email]>:

>
>> Now interface could look like this: https://lut.im/se396lam/fEK9513X
>>
>> p.p.s
>> Sorry for the long letter :).
>>
>>
>
> Maksim,
>
> First of all, thank you for the long letter! It was good of you to share
> the findings of your research into this matter.
>
> The screenshot looks like the right basic idea. I wouldn't expect to see
> spin boxes on both the instrument line and the staff line--just one or
> the other.
>
> I would also expect it to eventually assign port and channel numbers
> sequentially (rather than 3s all the way down), but I assume you were
> just doing a quick mockup/prototype.
>
> David
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/NeoTech
> _______________________________________________
> Mscore-developer mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/mscore-developer

------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Improving JACK MIDI Out

ChurchOrganist
In reply to this post by Maksim Grishin
Excellent work Maksim :)

This raises the point that the title of that window is now misleading.

I would suggest that the title should be "Assign Instruments" rather than "Create Instruments".

We are beginning I suspect to make the mixer window redundant.

I think channel/port controls should be there permanently, not just when JACK is selected for output, as Channel and Port is also relevant when sending to the internal synth.

They should, however be concealed either by shrinking the window left or by having a "More" button which makes this part of the interface visible.

In response to Lasconic's comments - maybe the whole MIDI engine for MuseScore needs looking at - certainly there are problems with controllers receiving the right values as evidenced by the problems we are currently having with the Pan control.

Regards
Michael
Regards
Michael
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Improving JACK MIDI Out

igevorse
> I would also expect it to eventually assign port and channel numbers
> sequentially (rather than 3s all the way down), but I assume you were
> just doing a quick mockup/prototype.
Yes, this quick sketch was only for demonstrating orientation in window.

And position of spinboxes is quite wrong.

There is new and I hope, final sketch: [0]
1. "Show MIDI Settngs" checkbox added
2. Spin boxes are belogs to the corresponding staves.


> Internally, which object would be associated with a port/channel.
> Instrument, Staff or Part?

Let's consider:
1. We can have a piano Part with 3 staves: for right hand, left hand and effects. Or even more staves for right and left hands. Why? Because on concerts, when playing synthesizer (I mean physical keyboard) I have to change tone/timbre and play different parts of the score with different sounds. So, Part couldn't be associated with a port/channel.
2. But internally Staff object only describes how score should look (hope, I understand it correctly). Instrument object describes, how score should sound. So, port/channel should be associated with Instrument class (There is already information about channel for internal synthesizer).

> I think channel/port controls should be there permanently, not just when
> JACK is selected for output, as Channel and Port is also relevant when
> sending to the internal synth.
Added checkbox for the permanent, you can see it here: [0].
But I don't have a use case for managing channel and port for the internal synth (If you have, write please). I think internal synth is the part of program that should feel minimum influence from user.


If there is no proposals more, I should begin implementing this on Monday.
Channels and port in this window would control only external JACK channel/port, not internal synth.
"Show MIDI Settngs" checkbox would be deleted.



------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Improving JACK MIDI Out

lasconic
Administrator
> 2. But internally Staff object only describes how score should look (hope, I
> understand it correctly). Instrument object describes, how score should
> sound. So, port/channel should be associated with Instrument class (There is
> already information about channel for internal synthesizer).

Indeed. However, the dialog you are showing only lists Parts and Staff
and not Instruments. A part can have several Instruments. The
instruments are listed in the Mixer.

lasconic

------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Improving JACK MIDI Out

ChurchOrganist
In reply to this post by igevorse
But I don't have a use case for managing channel and port for the internal synth (If you have, write please). I think internal synth is the part of program that should feel minimum influence from user.

If there is no proposals more, I should begin implementing this on Monday.
Channels and port in this window would control only external JACK channel/port, not internal synth.
"Show MIDI Settngs" checkbox would be deleted.


A couple of comments - firstly about this being only for JACK - there have already been requests for control over MIDI channel for the internal synth. This is largely related to the export of MIDI files for which the automatic assignation MuseScore gives causes problems with full orchestral scores when the resulting SMF is loaded into a sequencer - consider that currently MuseScore wil gobble 12 channels just for the string section of the orchestra - we need better control than that.

This is particularly relevant for organ music, and the use of the customised Jeux soundfont I am working on for use with MuseScore, where different staves may need to be defined as different instruments, and therefore be assigned to different channels, and, on rare occasions different voices may be required to have separate instruments, and therefore MIDI channels.

Secondly you need to amend your second implementation diagram to allow staves within an instrument to have channel assignations, for the same reason I have laid out above - as a synth player you should be able to appreciate that organists can have different sounds on 5 different keyboards/pedalboards at once and be playing up to 4 simultaneously.

HTH
Michael


Regards
Michael
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Improving JACK MIDI Out

igevorse
> However, the dialog you are showing only lists Parts and Staff
> and not Instruments.

I don't think so.
Look at the screen [0]. I took a default score, added 2 instruments via "Create Instruments" dialog.
I didn't create any parts, only instruments with staves.
Now I have 3 instruments: Piano, Electric Guitar, Piano, but I do not have parts.
Look at the screen: there is no parts in "MuseScore: Parts" dialog (File->Parts). [0]

Or you're talking about another parts? Anyway, picture shows that there are *instruments* in "Create instrument" dialog (strange?). If I am wrong, correct me.


> A couple of comments - firstly about this being only for JACK - there have
> already been requests for control over MIDI channel for the internal synth.

I got your problem. It have to be solved!
I think there is no need for *another* port/channel couple for the inner sequencer/synth, so we can use these [1] port/channel settings for both inner and JACK MIDI sequencer/synth.


> Secondly you need to amend your second implementation diagram to allow
> staves within an instrument to have channel assignations

You're talking about something like this, as I understand: [2].
It is pretty well and looks good, but current architecture does not allow to do this. As I wrote in my previous message:
> Staff object only describes how score should look. Instrument object describes, how score should sound.
So, there is some logical separation.
We can't assign channels for staves, only instruments can have channels.

There are 3 possible ways to go:
1. Add ability to add channels to staves. It brokes the logical separation of code (community would be against it, maybe).
2. Join two objects Instruments and Staves into one. We can only have Staves, they would have all properties of Instruments including channels. This would mess up a lot of code, developers couldn't code for a week (month?), and it would make a lot of new bugs. (But, really, I think that's the best option - all info about staff should be inside staff.)
3. Leave it as we have now.

If we choose the 3rd option, we get this: you need to assign channel to a staff, but only instruments could have channels. Solution: you need create an instrument for each staff, and assign channel to this instrument. 

I hope I am clear enough.

Questions that need to be answered:
1. Does "Create Instruments" contains Instruments? Is this sketch correct? [1]
My answer: Yes. What's yours?
2. Does controls in [1] should change Instruments' channel for inner and outer synth? If yes, controls would be permanent, showing when checkbox "Show MIDI Settings" is checked.
My answer: Yes. What's yours?
3. ChurchOrganist wrote:
> Secondly you need to amend your second implementation diagram to allow
> staves within an instrument to have channel assignations
I wrote my opinion above. What's yours?

As always, I am glad to hear your proposals about JACK.


------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Improving JACK MIDI Out

David Bolton-2
On 6/6/2014 2:24 PM, Igevorse Otonnoleare wrote:
>
> 2. Does controls in [1] should change Instruments' channel for inner
> and outer synth? If yes, controls would be permanent, showing when
> checkbox "Show MIDI Settings" is checked.
> My answer: Yes. What's yours?
>
> [1] https://lut.im/X4pnW37X/QoFUjUy2
>

Igevorse,

This is a super small thing, but I'd prefer if the "Show MIDI Settings"
checkbox was on the right side so that is is visually associated with
the right panel.

I don't know MuseScore's code well enough to speak to your other questions.

David


------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Realtime midi input: to be or not to be?

David Bolton-2
In reply to this post by igevorse
Igevorse,

I enjoyed reading your latest blog post: "Realtime midi input: to be or
not to be?"
http://igevorse.lited.net/p7.html

I tried to comment on the blog but I'm not sure it went through. Here's
a copy of what I wrote. My point isn't to say it is impossible, but to
say that it is more difficult that it might seem at first glance.


Real-time MIDI input has several difficulties that are not addressed by
a simple algorithm (like the one you mention). Here's an overview of the
difficulties that come to mind right now:


For single-note instruments (such as wind instruments) the main issues are
1. Difficulty of playing exactly to the beat with accurate pitches
2. Difficulty of playing the exact length of notes: repeated notes or
large interval jumps are often impossible to play for full value using a
MIDI keyboard
3. Figuring out the correct note spelling for any given note (For
complex scores this could be a summer of work unto itself)
4. The inability to add musical markings as you go. In programs (such as
Finale) that let you add almost any musical marking via keyboard
shortcut, the inability to add musical markings as you go represents a
significant loss of time (since it requires mode switching) and accuracy
(since it is easier to miss a marking on a second glance over the notes).


For multiple-note instruments (such as keyboard), in addition to the
difficulties mentioned above:
1. Difficulty of playing a block chord versus a slight arpeggio, and the
difficulty for the computer to interpret a rolled chord versus a series
of notes
2. The habit of pianists shortening note lengths (while holding the
pedal) to prepare to play the next chord. This is often a physical
requirement to play the next chord on time
3. The habit of pianists playing a note length longer than written
(since it fits the chord and sounds fine)
4. The difficulty for the computer to interpret whether the written
notation should reflect a longer note value because the pedal is down or
not.
5. There are many ways to write out what the pianist played, and
frequently the simplest/preferred written form differs slightly from
start and release of the notes in practice
6. Multi-voice staves can be interpreted as a mess of tied notes by
real-time input although Andrey Tokarev did a fantastic job of cleaning
this up for MIDI import last summer.


With enough research, coding, and testing perhaps all of these issues
can be overcome. However, the real question is real-time MIDI input
actually useful.

Since real-time MIDI input requires accurate pitches and strict
adherence to the beat the target audience is well-trained musicians. In
all but the simplest cases a well-trained musician can input their music
quicker using non-real-time methods (at least in Finale and other
scorewriting software that streamline other methods of score entry
including full use of keyboard shortcuts for musical markings during
note input).

MuseScore could use some streamlining to speed up the existing score
entry methods and bring it up to par with Finale, but it would take
considerable resources to streamline real-time note entry to the point
that is overtakes other methods of score entry in speed and accuracy.

David

------------------------------------------------------------------------------
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Realtime midi input: to be or not to be?

igevorse
Sorry, there was a bug with comments. Now it's fixed.

Thank you for the detailed description of difficulties!

Note: I do not propose realtime midi input as replacement for another input methods! I do not insist that people should use this feature for creating complex scores, it could be used for recording very simple melodies when_user_does_really_need_it.

About single-note instruments: while writing post I thought only about keyboard or midi-guitar.

By your items:
1. As I understand, midi can describe only accurate pitch, so it's a problem of emitter of midi-message (wind instrument?). About playing exactly to beat - it depends on the skills of player. Also, I already mentioned about precise note playing: I think user should select the minimal note duration (like in midi import) or some "Note latency", so that algorithm will align notes to beats. But yes, if we use notes with durations from 1/32 to 1, it would be a hard problem (see possible solution below - a killer feature).

2. Exact length can be compensated by changing some settings (choosing the minimal note length again?).

3. What do you mean by note spelling? Drawing D# or E flat? I didn't write (or I wrote?) in my post that before recording user should prepare an empty track (staff) with time signatures and tempos. So, adding tonality (accidentals) could be a solution. So, we could determine right spelling using tonality. But, again, there could arise some problems (for example, while using a phrygian, lydian, etc. mode. Also could be fixed by adding ALL possible tonalities and modes in settings.)

4. See "Note" above.

About multiple-note instruments and pedal. We can record note duration "as is" and record PEDAL_ON/PEDAL_OFF messages. MuseScore would play this file as you need - because synth, having information about pedal, would make note duration larger. Or, the second way is to compute note length manually, knowing that pedal is pressed.
I think the first way is better.

About other options - I have two possible solutions.

1. Make a lot of checkboxes in settings like "Use slight arpeggio, not a  block chord", "Be ready for the shortened note length", and so on like settings in midi import. With this settings you can adjust algorithm's behaviour to your playing style.

2. My killer-feature: give user a choice! :)
Cases that you described have common property - information about note can be processed differently.
Idea: allow user to choose one of variants of drawing notes. If algorithm detected some strange situations which can be processed differently, it gives a choice to user.

Example: [0]
This gives an ability to make changes just in two clicks. Also, there are could be 3, 4 or more local variants of part.


Also, lasconic mentioned that maybe it's better to record midi messages to midi file and open it via midi import.
If I use this way and play dirty (not accurate, shortened durations, etc.), I would get an exact copy of what I've played - a mess!
But if I use some realtime algorithms that can analyse notes, I could get a better output (well aligned notes, right note durations, etc.).

Did I miss something?

[0] https://lut.im/Z2ALUvBq/4wjJ23I2
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Realtime midi input: to be or not to be?

David Bolton-2
On 6/11/2014 1:20 PM, igevorse wrote:
> Note: I do not propose realtime midi input as replacement for another input
> methods! I do not insist that people should use this feature for creating
> complex scores, it could be used for recording very simple melodies
> when_user_does_really_need_it.
Yes, I understood.

> About single-note instruments: while writing post I thought only about
> keyboard or midi-guitar.
> By your items:
> 1. As I understand, midi can describe only accurate pitch, so it's a problem
> of emitter of midi-message (wind instrument?). About playing exactly to beat
Just to clarify, I was thinking of the user inputting notes for
single-note instrument staves but actually using a MIDI keyboard (think
orchestral scores, where the user inputs each staff with a MIDI keyboard).

> 2. Exact length can be compensated by changing some settings (choosing the
> minimal note length again?).

I was actually thinking of the instances where the note lengths differed
more than the quantization settings or minimum note length. For example
a quarter note may be played as an 8th note or shorter (and held by the
pedal while the fingers prepare for the next chord).

> 3. What do you mean by note spelling? Drawing D# or E flat? I didn't write
> (or I wrote?) in my post that before recording user should prepare an empty
> track (staff) with time signatures and tempos. So, adding tonality
> (accidentals) could be a solution. So, we could determine right spelling
> using tonality. But, again, there could arise some problems (for example,
> while using a phrygian, lydian, etc. mode. Also could be fixed by adding ALL
> possible tonalities and modes in settings.)

Yes, that is what I meant by note spelling (D sharp versus E flat based
on context). But I wouldn't worry about it for now. The other issues are
more significant and should be overcome first.

> 4. See "Note" above.
>
> About multiple-note instruments and pedal. We can record note duration "as
> is" and record PEDAL_ON/PEDAL_OFF messages. MuseScore would play this file
> as you need - because synth, having information about pedal, would make note
> duration larger. Or, the second way is to compute note length manually,
> knowing that pedal is pressed.
> I think the first way is better.
I agree the first option is better. My point was that the pedal messages
can't be relied on for note length, because occasionally it means the
notes should be written with longer but usually it doesn't (and it would
take a lot of analysis to determine which method is best from the context).

If you are a keyboard/piano player, play through some pieces (such as
4-part hymns) using the real-time MIDI input in other software and I
think you'll get a sense for what I mean.


> About other options - I have two possible solutions.
>
> 1. Make a lot of checkboxes in settings like "Use slight arpeggio, not a
> block chord", "Be ready for the shortened note length", and so on like
> settings in midi import. With this settings you can adjust algorithm's
> behaviour to your playing style.
>
> 2. My killer-feature: give user a choice! :)
> Cases that you described have common property - information about note can
> be processed differently.
> Idea: allow user to choose one of variants of drawing notes. If algorithm
> detected some strange situations which can be processed differently, it
> gives a choice to user.
>
> Example: [0]
> This gives an ability to make changes just in two clicks. Also, there are
> could be 3, 4 or more local variants of part.
>
>
> [0] https://lut.im/Z2ALUvBq/4wjJ23I2
>
I like the presentation in option 2 since it shows the options in
context using music notation (rather than overwhelming the user upfront
with theoretical scenarios described with words and checkboxes). Option
2 probably needs to present the user with the choice to set the default.
(Maybe something like "Stop automatically simplifying to block chords"
(similar to Microsoft Word and its automatic formatting context menus).

Of course, your "killer-feature" would require more time to code than
option 1.

David

------------------------------------------------------------------------------
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Improving JACK MIDI Out

igevorse
In reply to this post by David Bolton-2
I worked on JACK Transport before, but now I again work on "assigning channels for instruments".
I have some progress: I can change channels in Mixer window and when playing via JACK &Qsynth I see that channels changed. I can pick channels in any order and pick the same channels for different staves.

You can see the screenshot of new mixer window here: [0]
Note, it is not the sketch, it's a working solution.
I didn't implemented it only for JACK, so when I change channels in mixer I change the internal values in midi-system of MuseScore. And these values are also used for midi export.

My further plan is:
1. Check midi export: do channels export right?
2. Save channels to score file (mscz/mscx?) and restore on loading.



------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Improving JACK MIDI Out

Emile Ellberger
Hi,
Just curious to know if your work has any influence on the MIDI output- in particular if MIDI 1 rather than MIDI 0.
thanx for your feedback.
By the way this query is in regards to our SSMN research and our MuseScoreSSMN version of MuseScore.
All the best,
Emile Ellberger

On 20 juil. 2014, at 20:01, Igevorse Otonnoleare <[hidden email]> wrote:

I worked on JACK Transport before, but now I again work on "assigning channels for instruments".
I have some progress: I can change channels in Mixer window and when playing via JACK &Qsynth I see that channels changed. I can pick channels in any order and pick the same channels for different staves.

You can see the screenshot of new mixer window here: [0]
Note, it is not the sketch, it's a working solution.
I didn't implemented it only for JACK, so when I change channels in mixer I change the internal values in midi-system of MuseScore. And these values are also used for midi export.

My further plan is:
1. Check midi export: do channels export right?
2. Save channels to score file (mscz/mscx?) and restore on loading.


------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer


------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Improving JACK MIDI Out

igevorse
Hi. My current work on assigning channels would have minimal influence on MIDI output. Exported midi file already have information about midi channels, but MuseScore assigns them automatically. I just let user to select them explicitly.
Currently we use MIDI 1 format and it is convenient enough for implementing what I want, so there is no need to change format.

------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Improving JACK MIDI Out

muselabs
In reply to this post by igevorse
JACK support in musescore is much needed, agreed.  Thank you for working on it!

The Mixer mockup you show is good in having everything in one obvious place.  http://musescore.org/sites/musescore.org/files/issues/mscore-jack-midi-channel0-after01.png

The AVlinux debian distro has worked out Lots of JACK knots;  see bandshed.net and the distro itself.  AV linux is pure debian except that Audio apps with fixes in the AVlinux archive override their congeners in the debian archive [for squeeze].  More details comparing its sound module structure below.

    The current mscore nightly of 20140722 64bit for linux required addition of numerous libqt5 packages to linuxmint17 to run, per my testing yesterday.  (This host was not LMDE but based on ubuntu 14.04LTS, successor to the nightly's host distro for 64bit compilation-- information courtesy of Robert Leleu.  The corresponding 32bit nightly got no further in its host lubuntu 14.04 than the spashscreen before dying.)

  JACK had been added and was working with qjackctl  in linuxmint17 also, but settings in the mscore did not yield sound except with solely *internal synthesizer...PulseAudio*, and that only after adding soundfont FluidR3_GM.sf2 in the mscore nightly's Synthesizer pane.  Sound in MuseScore 1.3 worked only under the same settings in that OS environment.

DETAIL on what JACK attaches to in avlinux vs. linuxmint17 (based on ubuntu 14.04LTS) in the test machine (libjackd2 1. 9.9.5 ...); i5 with Intel soundcard
 ------
linuxmint17  

kernel and sound modules:  vmlinuz-3.13.0-24-generic

@lxmint17 ~ $ lsmod |grep snd
snd_hda_codec_hdmi     46207  1
snd_hda_codec_realtek    61438  1
snd_hda_intel          52355  3
snd_usb_audio         153411  0
snd_hda_codec         192906  3 snd_hda_codec_realtek,snd_hda_codec_hdmi,snd_hda_intel
snd_usbmidi_lib        29215  1 snd_usb_audio
snd_hwdep              13602  2 snd_usb_audio,snd_hda_codec
snd_seq_midi           13324  0
snd_seq_midi_event     14899  1 snd_seq_midi
snd_pcm               102099  4 snd_usb_audio,snd_hda_codec_hdmi,snd_hda_codec,snd_hda_intel
snd_rawmidi            30144  2 snd_usbmidi_lib,snd_seq_midi
snd_page_alloc         18710  2 snd_pcm,snd_hda_intel
snd_seq                61560  2 snd_seq_midi_event,snd_seq_midi
snd_seq_device         14497  3 snd_seq,snd_rawmidi,snd_seq_midi
snd_timer              29482  2 snd_pcm,snd_seq
snd                    69238  19 snd_hda_codec_realtek,snd_usb_audio,snd_hwdep,snd_timer,snd_hda_codec_hdmi,snd_pcm,snd_seq,snd_rawmidi,snd_usbmidi_lib,snd_hda_codec,snd_hda_intel,snd_seq_device,snd_seq_midi
soundcore              12680  1 snd
snd                    69238  19
---------------

 JACK works nicely with many apps --  but not with musescore 1.3 or earlier -- in debian AVlinux (jackd1 1:0.122.1avlinux1 -- you may want to see what changes AVlinux has in JACK).  These are the corresponding settings.
     (Machine i5, Intel, kernel modules when running in DEBIAN under vmlinuz-3.6.11.2-avl1 a realtime kernel of AVlinux (6.0.1b).

@avlx601b:~$ lsmod |grep snd
snd_aloop               9712  0
snd_hda_codec_hdmi     18333  1
snd_hda_codec_realtek    41129  1
snd_hda_intel          18934  2
snd_hda_codec          51326  3 snd_hda_codec_realtek,snd_hda_codec_hdmi,snd_hda_intel
snd_pcm_oss            27018  0
snd_mixer_oss           9781  1 snd_pcm_oss
snd_pcm                48030  5 snd_pcm_oss,snd_aloop,snd_hda_codec_hdmi,snd_hda_codec,snd_hda_intel
snd_page_alloc          4722  2 snd_pcm,snd_hda_intel
snd_seq_dummy            912  0
snd_seq_oss            19028  0
snd_seq_midi            3245  0
snd_seq_midi_event      3617  2 snd_seq_oss,snd_seq_midi
snd_rawmidi            12126  1 snd_seq_midi
snd_seq                32239  6 snd_seq_midi_event,snd_seq_oss,snd_seq_dummy,snd_seq_midi
snd_seq_device          3513  5 snd_seq,snd_rawmidi,snd_seq_oss,snd_seq_dummy,snd_seq_midi
snd_timer              12046  2 snd_pcm,snd_seq
snd                    34878  17 snd_hda_codec_realtek,snd_pcm_oss,snd_aloop,snd_timer,snd_hda_codec_hdmi,snd_pcm,snd_seq,snd_rawmidi,snd_hda_codec,snd_hda_intel,snd_seq_oss,snd_seq_device,snd_mixer_oss
soundcore               3247  1 snd

diffs:  avlinux has snd_aloop, snd_pcm_oss, snd_mixer_oss, snd_pcm_oss, snd_seq_oss, snd_seq_dummy; linuxmint has usb_audio, snd_hwdep, snd_page_alloc, snd_usb_midi_lib instead.

Maybe this might help in your work, although AVlinux, which is good with JACK, is squeeze-based (debian 6 I believe) and ubuntu 14.04 (April 17, kernel 2.13) is probably wheezy-or-later based as 7.6 was released July 12 as debian stable.  (I don't know if oss submodules have been absorbed into their header or something.)
 More power to ya!
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Improving JACK MIDI Out

muselabs
[replying so posting will take place]

On Thu, July 24, 2014 11:37 am, muselabs [via MuseScore Developer] wrote:

> JACK support in musescore is much needed, agreed.  Thank you for working
> on it!
>
> The Mixer mockup you show is good in having everything in one obvious
> place.
> http://musescore.org/sites/musescore.org/files/issues/mscore-jack-midi-ch
> annel0-after01.png
>
> The AVlinux debian distro has worked out Lots of JACK knots;  see
> bandshed.net and the distro itself.  AV linux is pure debian except that
> Audio apps with fixes in the AVlinux archive override their congeners in
> the debian archive [for squeeze].  More details comparing its sound module
>  structure below.
>
> The current mscore nightly of 20140722 64bit for linux required addition
> of numerous libqt5 packages to linuxmint17 to run, per my testing
> yesterday. (This host was not LMDE but based on ubuntu 14.04LTS, successor
> to the nightly's host distro for 64bit compilation-- information courtesy
> of Robert Leleu.  The corresponding 32bit nightly got no further in its
> host lubuntu 14.04 than the spashscreen before dying.)
>
>
> JACK had been added and was working with qjackctl  in linuxmint17 also,
> but settings in the mscore did not yield sound except with solely
> *internal
> synthesizer...PulseAudio*, and that only after adding soundfont
> FluidR3_GM.sf2 in the mscore nightly's Synthesizer pane.  Sound in
> MuseScore
> 1.3 worked only under the same settings in that OS environment.
>
>
> DETAIL on what JACK attaches to in avlinux vs. linuxmint17 (based on
> ubuntu 14.04LTS) in the test machine (libjackd2 1. 9.9.5 ...); i5 with
> Intel
> soundcard ------
> linuxmint17
>
> kernel and sound modules:  vmlinuz-3.13.0-24-generic
>
> @lxmint17 ~ $ lsmod |grep snd
> snd_hda_codec_hdmi     46207  1 snd_hda_codec_realtek    61438  1
> snd_hda_intel          52355  3 snd_usb_audio         153411  0
> snd_hda_codec         192906  3
> snd_hda_codec_realtek,snd_hda_codec_hdmi,snd_hda_intel snd_usbmidi_lib
> 29215  1 snd_usb_audio
> snd_hwdep              13602  2 snd_usb_audio,snd_hda_codec snd_seq_midi
> 13324  0
> snd_seq_midi_event     14899  1 snd_seq_midi snd_pcm               102099
> 4
> snd_usb_audio,snd_hda_codec_hdmi,snd_hda_codec,snd_hda_intel snd_rawmidi
> 30144  2 snd_usbmidi_lib,snd_seq_midi
> snd_page_alloc         18710  2 snd_pcm,snd_hda_intel snd_seq
> 61560  2 snd_seq_midi_event,snd_seq_midi
> snd_seq_device         14497  3 snd_seq,snd_rawmidi,snd_seq_midi snd_timer
> 29482  2 snd_pcm,snd_seq
> snd                    69238  19
> snd_hda_codec_realtek,snd_usb_audio,snd_hwdep,snd_timer,snd_hda_codec_hdm
> i,snd_pcm,snd_seq,snd_rawmidi,snd_usbmidi_lib,snd_hda_codec,snd_hda_intel
> ,snd_seq_device,snd_seq_midi
> soundcore              12680  1 snd snd                    69238  19
> ---------------
>
>
> JACK works nicely with many apps --  but not with musescore 1.3 or
> earlier -- in debian AVlinux (jackd1 1:0.122.1avlinux1 -- you may want to
> see what changes AVlinux has in JACK).  These are the corresponding
> settings. (Machine i5, Intel, kernel modules when running in DEBIAN under
> vmlinuz-3.6.11.2-avl1 a realtime kernel of AVlinux (6.0.1b).
>
> @avlx601b:~$ lsmod |grep snd
> snd_aloop               9712  0 snd_hda_codec_hdmi     18333  1
> snd_hda_codec_realtek    41129  1 snd_hda_intel          18934  2
> snd_hda_codec          51326  3
> snd_hda_codec_realtek,snd_hda_codec_hdmi,snd_hda_intel snd_pcm_oss
> 27018  0
> snd_mixer_oss           9781  1 snd_pcm_oss snd_pcm                48030  5
>  snd_pcm_oss,snd_aloop,snd_hda_codec_hdmi,snd_hda_codec,snd_hda_intel
> snd_page_alloc          4722  2 snd_pcm,snd_hda_intel snd_seq_dummy
> 912  0
> snd_seq_oss            19028  0 snd_seq_midi            3245  0
> snd_seq_midi_event      3617  2 snd_seq_oss,snd_seq_midi snd_rawmidi
> 12126  1 snd_seq_midi
> snd_seq                32239  6
> snd_seq_midi_event,snd_seq_oss,snd_seq_dummy,snd_seq_midi snd_seq_device
> 3513  5
> snd_seq,snd_rawmidi,snd_seq_oss,snd_seq_dummy,snd_seq_midi snd_timer
> 12046  2 snd_pcm,snd_seq
> snd                    34878  17
> snd_hda_codec_realtek,snd_pcm_oss,snd_aloop,snd_timer,snd_hda_codec_hdmi,
> snd_pcm,snd_seq,snd_rawmidi,snd_hda_codec,snd_hda_intel,snd_seq_oss,snd_s
> eq_device,snd_mixer_oss soundcore               3247  1 snd
>
> diffs:  avlinux has snd_aloop, snd_pcm_oss, snd_mixer_oss, snd_pcm_oss,
> snd_seq_oss, snd_seq_dummy; linuxmint has usb_audio, snd_hwdep,
> snd_page_alloc, snd_usb_midi_lib instead.
>
> Maybe this might help in your work, although AVlinux, which is good with
> JACK, is squeeze-based (debian 6 I believe) and ubuntu 14.04 (April 17,
> kernel 2.13) is probably wheezy-or-later based as 7.6 was released July 12
>  as debian stable.  (I don't know if oss submodules have been absorbed
> into their header or something.) More power to ya!
>
>
>
>
>
>
> ______________________________________
> If you reply to this email, your message will be added to the discussion
> below:
> http://dev-list.musescore.org/Improving-JACK-MIDI-Out-tp7578792p7578874.ht
> ml This email was sent by muselabs (via Nabble)
> To receive all replies by email, subscribe to this discussion:
> http://dev-list.musescore.org/template/NamlServlet.jtp?macro=subscribe_by
> _code&node=7578792&code=bXVzZWxhYnNAY29nbml6b3IuY29tfDc1Nzg3OTJ8LTIwMDU5N
> jIyMg==


12
Loading...