Am Mon, 02 Mar 2009 13:03:48 -0600 schrieb "Gabriel M. Beddingfield" <[email protected]>:
huhu, > [email protected] wrote: > >> If everyone else agrees that our users only plan to use the H2 transport > >> with > >> Ardour 2.7.1 and 3.x... then yes, let's take out the transport adjustment. > > yes, imo people who build and use actually versions of h2 also do this also > > with > > other software. also, ardour 2.7.x is in this moment standard in most > > distribution's. > > so i think it's ok when h2 0.9.4 maybe in 1 - 9 month work stable with this > > and newer > > versions. > > Sorry, I wrote that in a somewhat intimidating manner, didn't I? What I mean > is > this: if we all agree to *not* support Ardour's bug, then I'm OK with taking > it > out. > > However, I don't agree to doing any buffer offsets -- unless we can turn them > off. super! i am sure we need no buffer offset as slave. all works fine. but as master h2 produce a double hit on start. i test this also without ardour! if h2 is master and you start the transport from a control panel like qjackctl. and this is no wrong solution. h2 will produce the double hit. this problem is solved if you subtract the buffersize on two places in code (only time master relevant peaces of the code). this is completely independent from any ardour bugs. also the only two known appt's which will follow an master correct is seq24 and h2. seq24 works really well with h2 as master. so please what is the problem here? ardour3 also can not follow tempo change from other master. so the new midi functions can not controlled correctly over h2. e.g. a deferred start from h2 beatcounter. rosegarden also try to become the transport master if it's possible. and can not follow as full featured transport slave. lmms brakes up all other jack apps beside himselve. on my system it's completely unusable together with other jack appt's. i don't know why they implement a jack driver? and of course they have no transport slave. i know only seq24 which can do this :-((. it's a really sad affair situation in the jack transport world. perhaps he become crazy ---------------------8<----------------------- and for me it's since 1 week uninteresting too, to have an working transport master in h2. because the fx_and_sample blahblah... have a nice working midi output. now i can drive up to 16 amsynths or hexters :-DD hehehe. so i need no arg...hrg gurgel grunz jack transport master anymore. und er sagte "na dann ist ja gut" (and he said 'well then yes') kick the master and enhance the slave to a great slave.... you already talk about this some month ago. ---------------------8<----------------------- > > > if you interpret the code you will see that bbt 110 will set on 0 - > > buffersize. that > > produce a negative value. > > > > hmm?. the function getArdourTransportAdjustment() returns getBufferSize(). > > so what is wrong if i say it's the same. i write "-" get buffersize and not > > = get > > buffersize. i only relpace getArdourTransportAdjustment() with > > getBufferSize(). > > because imo, this pref. option is deprecated and what do exactly the same > > thing but > > without test the pref. settings!! and i remove this buffersize offset in > > slave > > function. so frame 0 = 0 and not 0 - buffer offset. what works correct for > > the moment. > > The problem is that adding or subtracting any offset violates the principles > of > using the transport in the first place. The only Right reason for doing it > is > for latency compensation. There should be ZERO latency between H2 and > Ardour. > Transport frame 0 in H2 is transport frame 0 in Ardour. If not -- somone is > cheating. > > The buffer offset says that frame 1024 in Ardour is frame 0 in H2. This is > wrong. (That is, if you start jack with 1024 frames/period.) > > > sorry but what mean all the output? and when you get it? after tempochange? > > or after > > start? > > It "records" the transport state whenever it is rolling. It doesn't care > about > tempo changes or anything. When someone presses PLAY, it records. When > someone > pressed STOP, it waits. > > > also sound card samplerate is never exact. what means samplerate is a > > product from > > any divider from sound card quartz oscillator (if they have already one). > > so what can > > i do with usecs and fps which are not exact? and also sampler.cpp compute > > all output > > stream in the buffer size time. did your simple client incorporate this? > > don't > > misunderstand me but i try to learn how the timing function works. > > Samplerate has nothing to do with it. You probably know that whenever JACK > does > the process() callback, all we care about is the next nFrames samples. We > don't > care about the oscillators in the hardware, or what the time on the wall > clock > says... we just care about reading or writing the next nFrames samples. The > only reason why we care about the sample rate is so that we can resample our > waveforms. > > Usecs is simply provided by the JACK server in the jack_position_t.usecs > field. > All my little test program does is record what that value was. I included > it > because there may be cases it helps to understand what's happening in the > data > (but none of these cases really benefits from usecs). > > > in moment i think to get a sync start h2 and other clients or masters > > always need (or > > have to use) this given buffersize to compute the output. so if h2 plans to > > start the > > transport it must send a correct startframe. e.g to ardour. and that ardour > > can begin > > transport exactly h2 have to wait one buffersize. because ardour need and > > use this > > time to compute the right output. so if h2 is master hydrogen have to > > correct the > > "internal" transport to startframe - buffersize. if h2 is slave and you > > start also > > transport from h2 all exact information will compute in master this > > includes also the > > buffersize offset. so imo, this will work correct in all ardour >2.7.x. i > > don't know > > the sample function in ardour. but i think this function s really complex. > > to compute > > all the things you can do in ardour. > > No, this is handled by the transport controls. Whoever calls > jack_transport_locate() decides what the start frame is. Hydrogen and Ardour > are supposed to play whatever happens at frame # jack_position_t.frame. (In > other words, H2 and Ardour should have perfectly synchronized frames: 0, > 1024, > 2048, etc...) > > > the other way to handle a exact sync is to send only a whatever control > > signal to > > all clients and than after one period buffersize all clients and master > > start or do > > whatever control signal will send. but this method will cost 2 periods of > > buffersize. > > one period for sending the signal from any client or master to any clients > > or master. > > and a second period to sync the output of all the client and master sample > > engine. so > > imo, this is not the way how jack transport work. imo, in moment to sync > > all apps > > will only cost 1 periode buffersize from the trigger moment. what implement > > to > > compute the offset in one of the apps. mostly master app. my patch use > > buffersize > > offset as master and "no offset" as salve > > Did you know: There is *no* callback whenever the transport master CHANGES? > If > H2 is the transport master... but Ardour takes over -- there is *no* > notification of the change. So, if Ardour takes over as master... but H2 > still > *thinks* he's the master --- we're screwed. Right? We're making decisions this won't work! it's only 1 master possible. see "int conditional" on api http://jackaudio.org/files/docs/html/group__TransportControl.html#g2f778b068a7c71b6eb0d6f2a674777db but if ardour is master it's possible to control the transport main functions from other apps like qjackctl, h2, seq24. what means "play, stop, fwd, fwd, pause" is possible to control from client. but no infos about tempo, beat type, position and so on. this control only the master. > based on who's controlling the transport. (I discovered this in the last few > days.) > > We're not supposed to care who the transport master is. We're not supposed > to > make decisions based on who's controlling the transport. > > >> Here's rev 858: > >> > >> usecs=179454108209 fps=48000 frame=0 bpm=120 B:B:T=1:1:0 bbt_offset=0 > >> usecs=179454129526 fps=48000 frame=1024 bpm=120 B:B:T=1:1:0 bbt_offset=0 > >> usecs=179454150858 fps=48000 frame=2048 bpm=120 B:B:T=1:1:52 bbt_offset=0 > >> usecs=179454172379 fps=48000 frame=3072 bpm=120 B:B:T=1:1:60 bbt_offset=0 > >> usecs=179454193586 fps=48000 frame=4096 bpm=120 B:B:T=1:1:68 bbt_offset=0 > >> > >> ...not much better. > >> > >> What's more... the tick count is usually 8 ticks per period. But, with > >> your > >> patch we sometimes get a period with only 4 ticks (1:2:76 -> 1:2:80): > > > > do you read the jack transport bbt and jack transport frames. because h2 > > ticks from > > jack time master are not the same than h2 internal transport ticks. > > Hydrogen was the transport master for this test. The BBT given is whatever > Hydrogen wrote to the jack_position_t struct. Hydrogen wrote bpm, bar, beat, > and tick. (H2 doesn't supply bbt_offset, so it's assumed 0, per the Jack > docs.) really, the ticks including no information. if i write the master calback for h2, at first i drive him only with the n_frames_t and bpm!! no problem. then i put the beats and bars. this will works also with no problem. at least i implement to compute some ticks. but hey, there is no function only to display them in the nice qjackctl lcd display. that's all. test it and remove the "ticks code" from the callback. what do the ticks? every appt have his own resulution. > One would expect that BBT changes at an even pace if the tempo is not > changing. > Hydrogen does not do this at startup. > > > i am wrong if your displayed frames are not the jack transport frames. also > > all usec > > values differ around +/- 300 usec. > > usecs is supplied by the JACK server. > > >> Peace, > >> Gabriel > > > > also peace wolke :-) > > :-) > > -gabriel wolke :-D > ------------------------------------------------------------------------------ > Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA > -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise > -Strategies to boost innovation and cut costs with open source participation > -Receive a $600 discount off the registration fee with the source code: SFAD > http://p.sf.net/sfu/XcvMzF8H > _______________________________________________ > Hydrogen-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/hydrogen-devel > ------------------------------------------------------------------------------ Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H _______________________________________________ Hydrogen-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/hydrogen-devel
