Re: [LAD] Advanced Gtk+ Sequencer aka GSequencer now on GitHub
Am 03.04.2015 um 19:59 schrieb Fons Adriaensen: On Fri, Apr 03, 2015 at 03:05:56AM +, Joël Krähemann wrote: I don't want to do JACK, since it is believed to be somehow the Qt thing. Where do you get that sort of nonsense ? Fons, like ever, polite and friendly in his posts. :-) Maybe this impression results from, that Qjackctl is the most known interface to jack, but, Joël, jack itself is completely (GUI)toolkit independent. regards hermann ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Advanced Gtk+ Sequencer aka GSequencer now on GitHub
On Fri, Apr 03, 2015 at 03:05:56AM +, Joël Krähemann wrote: I don't want to do JACK, since it is believed to be somehow the Qt thing. Where do you get that sort of nonsense ? -- FA A world of exhaustive, reliable metadata would be an utopia. It's also a pipe-dream, founded on self-delusion, nerd hubris and hysterically inflated market opportunities. (Cory Doctorow) ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Advanced Gtk+ Sequencer aka GSequencer now on GitHub
On Fri, 3 Apr 2015, Hermann Meyer wrote: Am 03.04.2015 um 19:59 schrieb Fons Adriaensen: On Fri, Apr 03, 2015 at 03:05:56AM +, Joël Krähemann wrote: I don't want to do JACK, since it is believed to be somehow the Qt thing. Where do you get that sort of nonsense ? Fons, like ever, polite and friendly in his posts. :-) Maybe this impression results from, that Qjackctl is the most known interface to jack, but, Joël, jack itself is completely (GUI)toolkit independent. I would also say that in my opinion as a novice coder, the jack MIDI interface is easier to use. Any MIDI event has a known time of arival based on sample number. All incoming MIDI events are presented to the programer as complete events so you don't have to deal with running status. The only downside is longer sysex events. I think there is work underway to deal with this as well, but of course a long sysex no longer would have sample acurate timing (maybe the first part will be time stamped) or at least would have added latency (ie. it would no longer be real time anyway). But that is a problem rawmidi would have to deal with as well. I do not know if there is a particular byte count limit to sysex events or if it varies with jack latency (the length of the cycle). But if you expect users to use this live, then it needs to work with reasonably low latency. -- Len Ovens www.ovenwerks.net ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Advanced Gtk+ Sequencer aka GSequencer now on GitHub
On Fri, Apr 03, 2015 at 08:13:15PM +0200, Hermann Meyer wrote: Am 03.04.2015 um 19:59 schrieb Fons Adriaensen: On Fri, Apr 03, 2015 at 03:05:56AM +, Joël Krähemann wrote: I don't want to do JACK, since it is believed to be somehow the Qt thing. Where do you get that sort of nonsense ? Fons, like ever, polite and friendly in his posts. :-) I politely and friendly disagree :-) I did not comment on the OP, not even on his personal beliefs since he wrote 'it is believed' and not 'I believe'. And what I commented on - the suggestion that Jack is somehow related to Qt - is nonsense. And even if it were true, so what ? Do we expect people to write apps to glorify some GUI toolkit and avoid anything related to another GUI toolkit, or do we expect useful apps ? Ciao, -- FA A world of exhaustive, reliable metadata would be an utopia. It's also a pipe-dream, founded on self-delusion, nerd hubris and hysterically inflated market opportunities. (Cory Doctorow) ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Advanced Gtk+ Sequencer aka GSequencer now on GitHub
On Fri, 3 Apr 2015 20:16:37 +0100 Gordonjcp gordon...@gjcp.net wrote: On Fri, Apr 03, 2015 at 11:46:17AM -0700, Len Ovens wrote: The only downside is longer sysex events. I think there is work underway to deal with this as well, but of course a long sysex no longer would have sample acurate timing (maybe the first part will be time stamped) or at least would have added latency (ie. it would no longer be real time anyway). But that is a problem rawmidi would have to deal with as well. I do not know if there is a particular byte count limit to sysex events or if it varies with jack latency (the length of the cycle). But if you expect users to use this live, then it needs to work with reasonably low latency. I can't help but think that if you're doing something that requires sample-accurate sysex messages, you're doing something a bit strange and wrong :-D From the hardware viewpoint SysEx events can be effectively infinite. The header contains the number of bytes in the block, so the number representation limits the block size, but synths can, and do, send multiple blocks. There is nothing in the spec limiting them! I think my old QS300 sends about 9 or 10 blocks for a complete system save, and takes 4 or 5 seconds to do so. During this time it can do nothing else at all. One of the problems is there is no agreed method of determining when the last block has been sent :( This may have changed of course. The last time I got involved in trying to manipulate MIDI messages was mid to late 1990s. -- Will J Godfrey http://www.musically.me.uk Say you have a poem and I have a tune. Exchange them and we can both have a poem, a tune, and a song. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Advanced Gtk+ Sequencer aka GSequencer now on GitHub
On Fri, 3 Apr 2015 15:37:27 -0400 Paul Davis p...@linuxaudiosystems.com wrote: On Fri, Apr 3, 2015 at 3:35 PM, Will Godfrey willgodf...@musically.me.uk wrote: From the hardware viewpoint SysEx events can be effectively infinite. The header contains the number of bytes in the block, so the number representation limits the block size, not true. sysex messages do not contain a size/byte count. the message content may include it, but that is not part of the sysex spec. I stand corrected. I'd seen it in both Yamaha and Roland manuals and obviously made an invalid assumption :( -- It wasn't me! (Well actually, it probably was) ... the hard part is not dodging what life throws at you, but trying to catch the good bits. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Advanced Gtk+ Sequencer aka GSequencer now on GitHub
On Fri, Apr 3, 2015 at 9:16 PM, Gordonjcp gordon...@gjcp.net wrote: I can't help but think that if you're doing something that requires sample-accurate sysex messages, you're doing something a bit strange and wrong :-D There are some cases where this actually makes sense, such as MTS tuning messages, if a sequencer or instrument plugin supports those (some do). Albert -- Dr. Albert Graf Computer Music Research Group, JGU Mainz, Germany Email: aggr...@gmail.com WWW:https://plus.google.com/+AlbertGraef ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Advanced Gtk+ Sequencer aka GSequencer now on GitHub
On Fri, Apr 03, 2015 at 11:46:17AM -0700, Len Ovens wrote: The only downside is longer sysex events. I think there is work underway to deal with this as well, but of course a long sysex no longer would have sample acurate timing (maybe the first part will be time stamped) or at least would have added latency (ie. it would no longer be real time anyway). But that is a problem rawmidi would have to deal with as well. I do not know if there is a particular byte count limit to sysex events or if it varies with jack latency (the length of the cycle). But if you expect users to use this live, then it needs to work with reasonably low latency. I can't help but think that if you're doing something that requires sample-accurate sysex messages, you're doing something a bit strange and wrong :-D -- Gordonjcp MM0YEQ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Advanced Gtk+ Sequencer aka GSequencer now on GitHub
On Fri, Apr 3, 2015 at 3:35 PM, Will Godfrey willgodf...@musically.me.uk wrote: From the hardware viewpoint SysEx events can be effectively infinite. The header contains the number of bytes in the block, so the number representation limits the block size, not true. sysex messages do not contain a size/byte count. the message content may include it, but that is not part of the sysex spec. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Advanced Gtk+ Sequencer aka GSequencer now on GitHub
On Fri, 3 Apr 2015, Gordonjcp wrote: I can't help but think that if you're doing something that requires sample-accurate sysex messages, you're doing something a bit strange and wrong :-D Even RPN/NRPNs start to wander from sample accurate Both are effectively single events that are sent as 4 events (12 bytes to send 4 bytes of info) A minimal sysex would be 7 bytes for the same task or 9 bytes with extended ID. This is assuming the first byte (of the four data bytes) can also tell the receiver what kind of data is coming. Of course the (N)RPN could be sent as 9 bytes too using running status. In Jack's case the (N)RPN is still 4 events while the sysex is one. Note: this page: http://www.philrees.co.uk/nrpnq.htm Suggests best practice for (n)rpn use includes nulling the parameter number with yet another two events, for 18 bytes or 13 with running status. -- Len Ovens www.ovenwerks.net ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
