On August 10, 2014 07:11:24 PM Robin Gareus wrote: Yeah I know. Bummer. Recorded waves are incorrectly shifted etc. I'm working very hard at the moment on adding automatic + manual latency compensation to MusE. It is sooo crucial - currently the top priority for me ! Man, it sure ain't easy, at least in MusE's case... PS: While on the subject... Regarding LADSPA and DSSI and VST DSSI plugins: Many of them report a latency through a 'latency' output port. But is there a standard? Do some report frames of latency while others report in milliseconds? Tim.

On Sun, August 10, 2014 10:11 am, Robin Gareus wrote: I guess I thought that happened when the track was armed, but I do know that some apps create new tracks if there are no armed tracks when the master record is hit. your answer made me think... hope it comes with someone to muck... -- Len Ovens www.OvenWerks.net

On August 11, 2014 10:05:59 AM Fons Adriaensen wrote: Mm, do you know about the 'slow-sync' Jack callback function? Or do you propose something slightly different? As in, able to report readiness anytime all the time even in stop mode? The 'slow-sync' Jack callback function is a great feature for holding up the transport until all the apps report they are 'ready to roll'. But, the callback is not polled until a transport start is initiated, whereupon the transport enters a special state JackTransportStarting and doesn't roll until all the apps agree, or a timeout value has expired. We already use the callback to hold off Jack Transport until we have updated our wave playback caches and so on - when everything is ready to roll. I reckon this callback will play a role in my efforts to add automatic + manual latency compensation to MusE: 'Live' stream sources such as Jack inputs, and routing paths which have plugin latencies, and so on, can be aligned simply by adding artificial delay (that's extra latency, but unavoidable) to the various paths so that everything aligns. But there is one stream source which has a trick up its sleeve: Playback sources. As in wave file playback (MusE Wave Track for example). These sources can be queued up ahead of time, and the only way I see to do that is to use the 'slow-sync' Jack callback. I can let the audio play for a moment while I hold up the Jack Transport and then let it go. There is one situation that is tough: when an external HW midi device initiates the play via midi play command for example. There is no way to tell it to hold off for a moment. Well, there might be, if the midi interface is bi-directional (in + out). Also, one could delay all input coming from the external HW midi device provided all its outputs are fed through the computer. But if for example its audio outputs are fed right into a mixer, well, out of luck there... I'm not sure that knowing all the time if the apps are ready to roll even in stop mode would be helpful. I mean, if the likely intention is to eventually go into play mode, then the 'slow-sync' Jack callback does what we need. Right? But... not ready for what? The app cannot know what the next transport intention is until the actual command comes down the line. For example a transport repositioning. So the 'slow-sync' Jack callback seems to be the only way to deal with this: Broadcast the actual command and wait until all the apps are ready to roll. Cheers. Tim.

On August 12, 2014 12:26:04 PM Fons Adriaensen wrote: Apologies, wasn't sure :-) Interesting... a pause state. OK I think I understand now: With the current system, the user 'presses play button', but the button then flashes informing the user it will be a few moments before we're actually running, then it stops flashing and system runs. With your proposal, the 'play' button flashes informing the user the system is busy - BUT - at least when it stops flashing, he is /guaranteed/ that the system will start immediately. I would add: If play is flashing he shouldn't have to press it again when it stops flashing, so let the system remember that he did in fact press play. Agreed. Yeah. Traditionally play is a mechanical state (as in "forward ho!") and record is not really a mechanical state but just a switch commanded to turn on the record circuit and head etc. That's why I tried to eek out some definitions yesterday but had trouble. Still, to satisfy the OP request, there could be a global record ENABLE, while still granting that record ARM is strictly a local thing. To rephrase your last sentence could be: Those that have local RECORD ARM enabled will record when started, provided global record ENABLE is on. Not sure about global punch in/out. Maybe. But as with the record functions, each app would have to have a way of letting the user elect to participate in the global override(s) or not. But, if the mechanism by which record functions could be added could easily include other commands such as punch in/out, why not eh? [Speaking my language here - Pro repair tech, 30+ years]: How would these decks be told by software to come out of deep-pause mode? To use my understanding of your proposal, paragraph above, the user's (software) play button would flash indefinitely (meaning not ready) until he presses it, and it'll be a moment until the VCR can be ready to play again. then we wait for a signal from the deck that it's ready. Which is what the slow-sync callback does. Seems both it and your proposal would be good to have? Ah... But you will say: A system where one of the decks is in deep-pause mode is not ready at all - it needs to be (manually) taken out or kept out of that mode when anticipating that recording will take place soon, to satisfy the instant run requirement. Right? MusE has pre-programmed punch in/out. Can't recall if can be activated remotely. Pleasure rappin' with ya. Tim.

On Wed, Aug 13, 2014 at 06:48:12AM +0200, Robin Gareus wrote: If we can use MIDI and stil play in sync with other musicians then surely a START command can be propagated to wherever it needs to arrive with acceptable delay. Pro tape decks could start in a few tens of ms at most. That was perfectly acceptable. And surely we can do better than that. Only pre-filling play buffers when a START command arrives is against all rules of sane RT design. Even when your disk systems are very fast. And it's easy enough to do it right. And yes, some bloated GUI systems can be sluggish but if you want your app to be responsive (e.g. for visual editing) you'll have to do something about that anyway. Nor should it be assumed that a START command is always given by a mouse click. 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)

On Wed, Aug 13, 2014 at 12:08:51AM -0400, Tim E. Real wrote: It's typical for video recorders (and DAT). Software apps wouldn't need one. How 'not ready' indicated is a side issue. It could be STOP flashing when stopped and PLAY flashing if you try to start, or some separate indication. The 'not ready' feedback exists to avoid the user trying to start when it will fail, so this shouldn't happen. But when it does, yes I'd agree that the start command should be remembered (as in fact it is now). Some of the tape machines I used could locate to some stored position, and while they were doing this you could hit PLAY. If the fast wind was forward they wouldn't even stop, just slow down when approaching the locate position to arrive there at the the correct speed and then go into PLAY. That's nice transport design. In software such things are almost trivial to implement, and they make a difference. Ardour fails here when controlled via OSC. If you send a 'locate' and then 'play' it will in many cases ignore the 'play' command. You need to insert a delay between the two to makes this sequence reliable. This hit me when I was writing the automated systems used at the CdS, which led me to write a dedicated player app and think a bit about reliable remote control protocols. That assumes that all apps have per-track record enables. A simple stereo recorder/player won't have them. Anyway, to set up recording you'd have to access the local user interface of that app, so having to enable record there is no big deal. To me it also feels safer. It's never a global thing. One app would do a punch in/out while the others are just playing. And if not you're doing something quite complicated, and this will need to be set up and checked locally on each app anyway. It would be local, or just by sending STOP. And most probably, when put into remote control mode any 'deep sleep' mode would be disabled. Anyway for SW apps such a state should not exist at all. They way I've implemented this in some players uses four states: all combinations of [STOP, RUN] and [READY, NOTREADY]. A state that includes NOTREADY is always transient, it will revert to the corresponding READY one as soon as possible. The combination RUN, NOTREADY is the one that Jack's 'slow sync' implements. But it doesn't have STOP, NOTREADY. So that is what I'd add, together with the requirement that NOTREADY must be transient, i.e. an app is allowed to be not ready but must always try to get ready ASAP, and not wait for e.g. a START command to do so. Being ready of course includes that the audio path is or can be set up, so things like only creating Jack ports when started (Audacity) are a definite no-go. Same here :-) -- 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)

On Wed, 13 Aug 2014, Fons Adriaensen wrote: To be honest, the reason I thought it would be nice is because I was looking at an app with no MIDI control in, but does have jack transport control. I was thinking that a master record enable was the one thing that traditional tape transports control clusters had that was missing. Of course just because it is traditional is not a great case for including it. On a tape machine all the controls are clustered for other reasons and the record arm sometimes does have more space around it or is sunken or has ridges on its sides. Having said that, most control surfaces that include a transport section and for that matter, most sw that has a transport section laid out in the gui, has the record enable included in that group. So it is a tradition that is still in common use. What would be called a defacto standard or a standard by tradition. Again I don't know if it is a good standard or not but that is where the hand of a recording machine operator will look for the record button. The next question is if a control surface should directly control jack transport. I think the answer is that enough people think is should that there are a number of standalone jack transport controlers around. Really the only thing missing is the record functionallity to be complete. Nudging and shuttling are already easy to do... I suppose scrubbing, or playing back at non-standard speed is not there, but I am not sure how that would be done and for now at least, this is not a universal thing that SW does, so most apps would ignore it anyway. A state that says make noise even if we are not in play, but we move the transport? The whole thing comes down to sync and the purpose behind it. This is much more common in Linux than other places because we can. The purpose is to take a number of applications and perhaps physical playback/record devices and to use them all as if they were one machine. From that POV, a single transport control makes sense. From that POV, using one control surface for more than one application/device also makes sense. I would suggest, however, that this practice is becoming less common as applications add more functions and become more "all in one". It seems that audio recorders now edit MIDI (and have instrument plugins) and MIDI editors record and playback sound. Even video can be included. When I first started doing music on computers, recording audio on a computer was just a dream. MIDI was no problem (if you stayed away from windows) and so audio was recorded on a tape machine and the computer sequencer followed the timecode stripped on track 8 (permanently set to record at -10db for this purpose). Sync was the only way to get enough tracks for many things. Not any more. Just to be complete... I have looked at OSC. OSC is very flexable. However, that flexability seems to be it's problem too. There is no way to create a generic control surface with /softwarename/track1/gain and then go "bank up/right" and have the mapping change to /softwarename/track9/gain within the software... no standards for this. To be fair, there was not in MIDI either till people started making control surfaces and the software had to deal with whatever they put out and that became the standard (The mackie control protcol for example). However, as a contol surface manufacture, why would I make an OSC product? What market share would that gain me? Really, in order to even create a middleware converter from MIDI controller to OSC would be a pain. I would have to do all the banking in that middleware. I would have to know all the strip names (takeing non-mixer as an example "/strip/stripname/pluginname/paramname param") and map them to a number... or name them in an unituitive manner in the first place. Ardour uses something totally different "/apname/route/function tracknumber param". The ardour method at least could be banked reliably. I suppose a patch bay kind of middleware that showed controler outputs and SW inputs for control could work, but it seems poor to have a user patch what would be normal routing for each project. OSC has a way to go, IMO, it is not ready to use with control surfaces. -- Len Ovens www.ovenwerks.net

On Wed, Aug 13, 2014 at 11:13:41AM -0700, Len Ovens wrote: One problem with OSC is that it is such a mixed beast. On the lowest level is a data encoding format, no semantics. But some of its features - structured paths and wildcards - only have value at a semantic level. But for the rest that level remains undefined. Ther result is that any control surface or similar device needs to be programmable, and whatever is done with it will be ad-hoc. It would be possible to define some standards, e.g. for transport control. But unless they are * very strictly defined, and those definitions are enforced in some way, * and the standard is designed to be as universal as possible, without making assumptions or including things that are correct only 99% of the time, any such standards are destined to fail. 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)

On Wed, 13 Aug 2014 21:12:54 -0700 (PDT) Len Ovens <len(a)ovenwerks.net> wrote: Wow! I hadn't realised it had been around for so long. In these posts, you described my own concerns pretty accurately. It could easily become a nightmare of incompatibility. If various bits of kit want to talk to each other, don't they all need a translation layer with separate lists for every device they know about? Also, while I can see that OSC fits very well for setup messages and general housekeeping, I wonder at the overhead incurred for time-critical messages. -- 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.

[Fons Adriaensen] I have to agree that this is a far more useful approach than jack's current "slow-sync" and I think that for jack to become a truly professional tool the adoption of this state model is inevitable. Tim

[Paul Davis] I beg your forgiveness for my very poor choice of words, but still I am hopeful, even certain, that this mistake of mine will not be able to taint your habitual power of objective consideration telling you that the current approach is inferior to Fons' proposal in a number of ways. Cheers, Tim

On Sun, 10 Aug 2014, Tim E. Real wrote: Ya midi is there, one way or another. Most Applications that support recording "something" and jack sync/transport also support punch in/out via a midi controler. MMC is supposed to be real time as well. I do not know the right answer. In my case I am making software for a midi control surface, but because the "midi" is generated after the signals get into the computer, I am also able to use the control surface to control jack transport directly (in fact that was easier than sending jack MIDI). From that point of view, having a record start would be an ideal global solution. Also, there is some software (the non-* group stands out in my mind) that does not have MIDI in for control purposes, but reacts to jack transport very nicely. One of the sub projects of this software is to split the computer keyboard so that the numeric keypad can be used as a midi/jacktransport control surface while the rest works as the system keyboard still, so I have an interest in a more complete jack transport from that POV. However, I am now using either and/or as the user sees fit. One way or another it will get done. It seems some controlers just send whatever midi note on is next on the table for record enable. However I am less worried about that because each key/switch can send a user set midi string/event. I will provide some preset ideas that seem useful to me. -- Len Ovens www.ovenwerks.net

On Mon, 11 Aug 2014, Tim E. Real wrote: MMC, from what I have read, seems to support two record enables: - arm tracks for recording. While these are in the realtime section of commands, I would think these would be the commands run before roll to give sw time to get things ready to record. - Then there is punchin/out or master recordenable which is meant to be realtime and should start the app recording with no transport stumble or wait. Now maybe there are people who think using track-rec-enable for punchin/out is the way to go, but I can't see myself working that way. I also do not think it would be the right thing to do, to expect jack transport (or any other transport) to arm tracks of multiple apps... or even one app, because this would assume a static number of tracks. The punch in/out master rec-enable does make sense though. all the enabled tracks would record at the same time. Yup. Ok, I, in my limited POV, don't see a need for this unless one of the apps fails to start recording and wants to signal this somehow. IMO, they are the same thing. When getting ready to play, anything that needs to be ready for record should be done too. The transport can not wait at the punch in point for sw to get ready or else the whole punch in concept is void. Any sw that has a track recenabled should be making sure it is ready to record on those tracks before playing. It _may_ be OK for an app to start recording some ms late provided the actual time of the record starting is saved as the punchin point for that app... this gets messy real quick though. If there is to be any "get ready time" at the record strobe, the play state must not change once started just for recording sake, better a system wide record start delay of the punch in point. I still feel the app should be ready to record anywhere from the play start with no delay. I would expect an old app to ignore it (them, punch in and out) and lets get fancy and ask for the moon... jack transport would of course drop in a MIDI port for telling these old apps to start recording :D With the variety of MIDI control surfaces around, one pretty much has to. And now having gotten my feet wet with jack midi stuff... I am thinking of a MIDI control surface mapping app that takes MIDI in from a control surface and splits it for a number of applications. The idea being that a controller that has 8 channels and does banks, might send controls for bank 1 and 2 to one app and bank 3 to a second and maybe bank 4 to a third. While it may be possible to auto figure out how many banks each app has, the operator might be better for settng it up and knowing what is what. Of course as apps become more "do everything" the use for such a thing may be waning. I have looked at OSC... but it has no standards (bad way of trying to make my point), each signal seems to have to be directed at a particular app/control. There seems to be no generic controls where a generic control surface can be used. Maybe that is because all the docs I have read are showing off it's flexablity. It seems even a native OSC control surface would need middleware to rename the signal so the destination was correctly chosen. -- Len Ovens www.ovenwerks.net