On Fri, Feb 15, 2013 at 10:33 AM, M Donalies <ingeniousnebbish(a)cox.net>wrote;wrote: It means that you have to do that tricky 'sequencing' part, which consists of scheduling (MIDI) events and only placing them onto the JACK buffer at the appropriate instant. ALSA MIDI does this for you, as well as providing a nice API for generating the MIDI events. That's not the trickiest part though, the real mess begins when you want to deal with the JACK Transport/Timebase API to follow or generate tempo changes.

On 15/02/13 M Donalies <ingeniousnebbish(a)cox.net> wrote: I expected the timebase stuff to be quite straightforward too, but found the details started to get a bit fuzzy when it comes to staying in sync as master and staying in sync as a slave; something to do with rounding errors and methods of calculation. Found it actually quite difficult, and with my program I don't think I actually came to find anything I considered a fully acceptable solution. (but coding is just a hobby for me that sometimes I get quite serious about and at other times (like the past six months or so) just can't be bothered with). But anyway, JACK MIDI isn't very difficult, NON Sequencer was one of the programs I found useful to study, perhaps you could take something from JACK Keyboard or VMPK, too. James.

On Fri, Feb 15, 2013 at 2:15 PM, Pedro Lopez-Cabanillas < pedro.lopez.cabanillas(a)gmail.com&gt; wrote: actually, if there is a JACK time master that has a notion of musical time (which is a choice of the user, not JACK), then JACK will also tell you the time in terms of bars and beats, along with the tempo and meter.

On Fri, Feb 15, 2013 at 12:53 PM, Pedro Lopez-Cabanillas < pedro.lopez.cabanillas(a)gmail.com&gt; wrote: [ ... ] nobody hates you, but it is irritating that you would say stuff like this. the history of JACK MIDI has very very little to do with Ardour, and indeed was conceived long before any work had even been discussed that would make Ardour a MIDI sequencer. not only that, but the guy who implemented most of JACK MIDI went on to work for a competing DAW company! so ... no, the goal was to allow the ecosystem of JACK clients to exchange MIDI data with (a) zero copy (b) sample accurate timing (c) correct thread semantics for synthesis. i have no idea why you find it necessary to disparage JACK MIDI in the way that you have done above. i think there are many perfectly sound arguments against JACK MIDI (they are almost symmetrically matched with arguments against the ALSA sequencer), but the "JACK MIDI was conceived so that Ardour would the rule the world" is silly and insulting.

On Fri, Feb 15, 2013 at 3:19 PM, M Donalies &lt;ingeniousnebbish(a)cox.net&gt;wrote;wrote: although flash is on its way out (thanks largely to apple, but also html5 + <canvas>), javascript is at the core of a lot serious website functionality. it actually makes a number of web-centric user experiences much more pleasant. follow the money ... who do you propose would write such documentation? why? the JACK API is fully documented. tutorials on basic use of the audio API exist. the big difference here is that there are several example blobs of source, ranging from the explicitly "example" clients within the JACK source code package itself, to the utility clients, and onward up to full scale MIDI sequencers such as ardour. But they also use Jack for audio. This is my frustration. If I want to which is, of course, another reason why JACK MIDI exists. look, the ALSA sequencer emerged at a time (1998 or so) when it was sort-of correctly believed that you couldn't do "realtime-y" stuff from user space on linux. although the functionality it offers is incredibly useful for quite a few purposes, the basic design assumption that this sort of thing must be done by handing data to the kernel and allowing it to be scheduled there is just wrong (or at best, unnecessary). nobody has ever stepped up to write a library based on JACK MIDI that would do "MIDI sequencing" in the sense of your "deliver this event at time T where T is arbitrary". nothing is stopping anyone from doing that. but ... i would point out that if you look carefully at the insides of the linux based sequencers you mentioned, you will find that they do not actually use this functionality of the ALSA sequencer either. they ask for "immediate" delivery and use their own sequencing mechanisms to get the timing right (mostly). the only effort i have seen in the open source world to implement a general purpose MIDI sequencing library that did "future" sequencing was something called (something like) TME3. it was a complete failure in terms of getting other apps to use it. "shouldn't there be a kind of general purpose JACK audio sequencer" makes about as much sense ... what could make quite a bit of sense would be a utility JACK client that played an SMF file via JACK MIDI. this would be *relatively* simple to do (once you figure out what godawful lump of code you plan to use to parse SMF) and would be quite instructional for future questions such as yours. however, this tool does not exist at this time. --p

On Fri, Feb 15, 2013 at 4:46 PM, J. Liles &lt;malnourite(a)gmail.com&gt; wrote: groovy. thanks for the correction. they even still build and appear to run correctly. M. Donalies - you should definitely take a look at this.

On Fri, Feb 15, 2013 at 10:46 PM, J. Liles wrote: ... Ther's also jpmidi. Playback only, written in C.

On Friday 15 February 2013 15:22:20 Paul Davis wrote: I suppose I've been spoiled by the Qt documentation. There are overviews for each framework, and each class and method have significant explanatory documentation, often including a sample of how to use it. The examples are well-documented, take you by the hand, and walk you through exactly what's going on at each line (or small group of lines). I find the Jack documentation much harder to follow. The refman opens with some broad explanations of what Jack is, then goes on to give short descriptions of each function and data type. There's no "here's how you use these guys" sections. Some of the Jack example files are commented and some aren't. There's also no expanded tutorial that takes you step by step from something completely trivial to a simple but functional program (e.g. Qt's tutorial, Scribble, if I recall). I don't mean to denigrate the documentation that's there, but it's missing something. It's like a bunch of disconnected man pages. It's okay if you already know how to use it, but it's very hard for the newbie. The Alsa documentation suffers from this as well. It's kind of like taking a calculus textbook and jumbling all the pages. You'd have hunt and peck through this page and that for a very long time before you could understand anything. For parsing an SMF, you mean something like code that can convert midi to text and back again? I've written a couple of converters to do that sort of thing. In the program, each midi track is a list of events with absolute times. Merging the tracks together isn't a big deal, so then I'd have a single list of events with absolute times (in midi ticks). I also have the code to convert each event to a list of bytes (binary data), since I can write a SMF. And I have an algorithm to convert absolute ticks to nanoseconds. It's that messy sequencing stuff that's giving me the trouble. -- 7:8

On Fri, Feb 15, 2013 at 11:41 PM, M Donalies &lt;ingeniousnebbish(a)cox.net&gt;wrote;wrote: Hi M! As a relative new-comer to linux-audio, I struggled with the same issues you're having. I had intended to document my own learning of JACK MIDI, and have a repo online here concerning exactly that. I just fixed the build errors, but unfortunatly there's only a very basic example currently available: If you would like to add to it, please do :) https://github.com/harryhaaren/JACK-MIDI-Examples In a similar fashion there's another repo for general audio programming tutorials. There's a bit more available there, but again maybe its a bit too basic for your needs. https://github.com/harryhaaren/openAudioProgrammingTutorials HTH, -Harry

Frankly I don't understand why you guys always take the occasion of such threads (that are purely technically motivated by someone asking for advice) to digg out your old disputes. Why can't you just accept that any concept that came up here has their pros and cons? I didn't see any dictator-like behavior in any of the previous arguments. If you don't like it noone obliges you to use jack or Qt or ALSA ;) and it's good that way no? Neither of the two MIDI APIs has evolved much in the last years, and I think that is the only thing to admit here Best Frank

On Feb 15, 2013, at 18:41 11, M Donalies wrote: You have been! I regard TrollTech's docs as the 'gold standard' for the entire industry; even M$ docs, for all their bloat, are not near as easy to use. Cheers! |-------------------------------------------------------------------------| | Frederick F. Gleason, Jr. | Chief Developer | | | Paravel Systems | |-------------------------------------------------------------------------| | ...one of the main causes of the fall of the Roman Empire was that, | | lacking zero, they had no way to indicate successful termination of | | their C programs. | | -- Robert Firth | |-------------------------------------------------------------------------|

On Friday 15 February 2013 15:19:03 M Donalies wrote: I suppose that it means that my work and I have been bullied in this mailing list in the past by the great benevolent dictator and guru. After that, I have become an old and angry drumstick. Regards, Pedro

On Sat, Feb 16, 2013 at 7:15 AM, Pedro Lopez-Cabanillas < pedro.lopez.cabanillas(a)gmail.com&gt; wrote: well i guess as the Great Dictator and Malevolent Guru, i am forced to comment again just so that you can remain sufficiently angry that you keep coding useful apps for people to use. let me know what else i can add that will get you sufficiently riled up. do i need to harp on about KDE some more? possibly critique some long dead technology like artsd once more? just let me know - it would be a shame to lose your talent and skills just because i stopped irritating you. that said ... your analogy is a good one, but it doesn't mention an important detail that matters a great deal from a development perspective. you can't see an SVG image without rendering it as a bitmap. inkscape does this for you, both while you work and when you decide to use "Export as bitmap". likewise, you can't hear MIDI without rendering it to audio. now, if someone uses a workflow in which they edit MIDI,then render, then listen, then go back to editing MIDI again, it is entirely reasonable to keep the audio and MIDI aspects of software rather separate. this is, in fact, how systems like CSound and RTMix and SuperCollider worked for many years. but as soon as someone wants to either (a) have their tool respond to incoming MIDI in realtime and/or (b) avoid the requirement for an edit/render/listen cycle, it becomes important to integrate the audio and MIDI parts of a piece of software fairly tightly. this by itself isn't so different from what inkscape does - after all, it can render bitmap images all the time as you edit. the added dimension for audio (and MIDI) though is ... time. the user can not only edit the data represented as MIDI and position it in different tracks/channels and arrange for different renderers (think "instrument plugins"), but the MIDI data itself contains a notion of "time" in the sense of "don't play me yet, do it in 1.2 seconds". this adds an entirely new dimension to the development task that simply isn't there for graphics (but is of course part of video). and it is the handling of the temporal aspect where tools like the ALSA sequencer come into play.

On Sat, Feb 16, 2013 at 10:49 AM, Bill Gribble &lt;grib(a)billgribble.com&gt; wrote: actually, its a duo. the problem is, i know which one i am but who is going to play the other one?

On Saturday 16 February 2013 13:15:51 Pedro Lopez-Cabanillas wrote: To complete the analogy, we should include computer hardware in the picture. When a vector graphics software application shows an image on a computer screen, it has rendered the picture using either a software only engine, or an accelerated one assisted by a computer graphics card, probably through OpenGL. CAD programs use also vector graphics, and their output is usually sent to plotters and 3D printers, that don't require bit-mapped renderings before materializing the output. Electronic musicians have MIDI synthesizers. Soft synths run on computers that may render MIDI sequences into digital audio directly. There are also hardware synths. In the past, hardware synths were included on almost all computer sound cards, sadly not anymore. Creative still ships Audigy cards containing a hardware MIDI synth, though. Anyway, many musicians own standalone hardware synths, and we are naturally conservative regarding good musical instruments. But synthesizers are not the only musical instruments that understand MIDI. For instance, the Yamaha Disklavier is a line of acoustic pianos with MIDI interfaces that don't synthesize anything. The sound is produced by hammers striking strings, as ever. There are other use cases for MIDI that don't involve soft synths, or even don't involve music at all. What I find laughable is the arrogance of pretending that everybody fits a single use case. Regards, Pedro

On Sat, 16 Feb 2013 20:13:33 +0100, Paul Davis &lt;paul(a)linuxaudiosystems.com&gt; wrote: I didn't follow this thread, I randomly read this. While MIDI can be used as an interface for non-music-things, jackd is an application for music usage. There are many issues with MIDI and I hope coders for music applications focus to optimize music application's MIDI for music usage and nothing else. If you like to use MIDI as a serial interface for something else, then I won't call it MIDI, but RS foo. You for sure won't take care about the MIDI protocol, e.g. running status, active sensing, _normal_ data vs SysEx etc., pp., but this is MIDI for and music software can't take care about other serial interface use cases.

Am 16.02.2013 20:31 schrieb "Ralf Mardorf" &lt;ralf.mardorf(a)alice-dsl.net&gt;et>: won't call it MIDI, Have you heard of MIDI Show Control?

Am 16.02.2013 23:23 schrieb "Ralf Mardorf" &lt;ralf.mardorf(a)alice-dsl.net&gt;et>: MSC has been an industry standard for 20+ years now. So who cares what MIDI was meant to be in the eighties? When I am concerned with MIDI it's about MSC.

Am 17.02.2013 00:06 schrieb "Ralf Mardorf" &lt;ralf.mardorf(a)alice-dsl.net&gt;et>: Except for the SysEx length there's no problem at all. I just wanted to show you that MIDI has been in use beyond music for years. of MIDI music issues and this is one of the music issues. You're completely underestimating what MSC is actually used for if you call it a music issue.

On Feb 15, 2013, at 15:19 03, M Donalies wrote: In a nutshell: because the communities to which the Linux kernel is relevant are larger, by several orders of magnitude. They also include significant multinational corporations who have bet their entire future on its success. The lack of audio programming docs used to upset me also, until I realized that, as pro audio developers, we're just a flea on the back of this elephant called Linux. I've learned to accept the fact that, when learning to do something new, I'm going to be spending a lot of time studying source code and reverse engineering other applications. That's a basic cost of working with a free (in both senses) and open system. Other systems exist that have well established documentation systems, but extract costs in other ways. Take your choice. Cheers! |-------------------------------------------------------------------------| | Frederick F. Gleason, Jr. | Chief Developer | | | Paravel Systems | |-------------------------------------------------------------------------| | "There are three principal ways to lose money: wine, women, and | | engineers. While the first two are more pleasant, the third is by far | | the more certain." | | -- Baron Rothschild, ca. 1800 | |-------------------------------------------------------------------------|

On Saturday 16 February 2013 03:58:10 Frank Kober wrote: A few people have mentioned tempo changes on the fly as a troublesome area. So let me think about this: Changing a tempo doesn't change the number of ticks. It does change the time value (in nanoseconds) of each tick. So suppose at time x a tempo change occurs. We let startTick = nanosToTicks(x) be our new starting tick for future calculations according to our new tempo. nanosToTicks() is then set to use the new tempo. So really our function could be nanosToTicks(x, tempo). This is essentially what we do if we're playing a smf with a tempo change. Presumably, what seems to concern people is an additional tempo adjustment (e.g. pushing a button to slow playback to half speed). But this is just a scale factor. Then we have nanosToTick(x, tempo, scale), which is the same calculation above except that we multiply by scale at the end. I don't really see the issue here. Or is everyone else talking about something different? -- 7:8

On Sun, Feb 17, 2013 at 3:57 AM, M Donalies &lt;ingeniousnebbish(a)cox.net&gt;wrote;wrote: This is indeed a "lovely" topic for debate. I'm bound to say that, I'm currently doing a final-year project for college on the topic. I've came up with a solution, which I feel is the best balance between C++-y style Event classes, and C-style simple code. Simple is great for RT situations: its easy to see if something is RT or not. In essence it boils down to this: -Create an "EventBase" class with pure virtual type() and size() functions -Derive actual events like "EventPlay" overriding type() and size() -Create a ringbuffer checkout the example, it uses the JACK ringbuffer -Create events *on the stack* ie EventPlay eventPlay(); -Write events into the ringbuffer using jack_ringbuffer_write(); The last two steps are key, as they enfore the event gets *copied* into the ringbuffer, and the original goes out of scope (and gets destroyed). This solution is very workable, on the condition that only fundamental C datatypes are passed trough the Event class. Things will get nasty if you pass std::shared_ptr<> objects trough it, I've made that mistake already :) The following code shows communication from the GUI thread to the RT thread. Create another ringbuffer and functions for communicating in the other direction. https://github.com/harryhaaren/realtimeAudioThreading HTH, -Harry

On Sun, Feb 17, 2013 at 9:20 PM, Paul Coccoli &lt;pcoccoli(a)gmail.com&gt; wrote: Nope, write them one sizeof( event->size() ) at a time. I'm very interested in why copying C++ objects like this is a bad idea. Its been discussed on list before ( http://linux-audio.4202.n7.nabble.com/Inter-thread-Communication-Design-App… ). This seemed to be the best simple RT safe solution. If you have suggestions / improvements I'd love to hear them. JACK ringbuffers are Pointers to an Event? Just makes it more hassle to send an Event from the RT thread. Involves taking X memory from a mem-pool, and then using placement new to construct the EventPlay(), and then send the pointer trough the ringbuffer. More complicated IMO. Indeed, that would be necessary. Again, more complications. That said, it can be done, and would involve less "traffic" trough the ringbuffer, and also "fixed size" traffic": pointers to EventBase.

On Sun, Feb 17, 2013 at 4:45 PM, Harry van Haaren &lt;harryhaaren(a)gmail.com&gt; wrote: The only reason you need this is because you memcpy the object. You're effectively serializing your object and passing them over the ringbuffer. If you do it this way, you should at least consider explicitly embedding the type and length as the first member of EventBase (and have each derived class set their own type and length in their constructors), and reading those before touching the object you read.