I have tested again the Jackdump sync, in master and slave mode, with Hydrogen Rythm Box.
Master :
It seems that Renoise sends the correct tempo to Hydrogen, but still miss the 1st line in loop pattern mode.
When the 1st loop is played (when I start the pattern), the 1st line is played.
But after, when the loop is starting again, the 1st line is always missed…for ever…
Slave :
Hydrogen sends the tempo to Renoise, and Renoise takes it (as I can see when I change the tempo in Hydrogen, Renoise shows the same).
The sound is not detuned as it was in Beta8…
When I start the pattern from Hydrogen, the first line is played 4 times [3 +1 (start of the sample)] in a very quickly looped mode…
Of course the pattern doesn’t scroll correctly.
So :
much more better in Master mode (but still the 1st line is missed)
This attachment is what it sounds like.
This is all internal midi routing between 2 instances of renoise through IAC.
The master is running an empty pattern of 64 lines looping.
The slave is running a pattern 32 lines 1 bar twice looping.
The master has ‘send song position pointers’ on.
The audible stumble after 4 bars, is when the master pattern of 64 is beginning again.
I tried adjusting the master Offset to -100 for compensation, though it doesn’t sound any different.
My point of view is that it kinda sounds like Renoise might be compensating back and/or forward against it (send song position pointer).
including this 4 giggles.
BPM 123 LPB 4
[details=“Click to view contents”]<?xml version="1.0" encoding="UTF-8"?>
<patternclipboard.blockbuffer doc_version=“0”>
Breemix: How do you get Hydrogen sending tempo info at all (being the master)? I’ve tested all this with Hydrogen 0.9.3 and can not really replicate any of the issues.
When dealing, playing with loops:
Quoted from Jack Transport - Renoise User Manual
“”“There is no loop information in Jack time bases. Every client will try to apply its own loops, fighting with the other Jack programs to reposition. To avoid this unwanted conflict, enable loops in the application that is currently active, is the timebase master, disable them in the others.”“”
Yay, thats the song position change that is sent from the master when restarting the pattern. If all you want is bar syncing two Renoises, the please disable sending Song Position Pointers for the master.
starting Hydrogen (0.9.4 svn), but should work with 0.9.3
disabling transport master in Renoise Preferences
Enabling J.Master in Hydrogen
Enabling transport master in Renoise Preferences
playing pattern or song in Hydrogen - It doesn’t work when nothing is played.
changing tempo in Hydrogen sends the same in Renoise (works good when you change the tempo directly with the keyboard numbers in Hydrogen, but disconnects Renoise from jackdump if I’m using the scroll mouse buton or the +/- tempo bouton, as it uses a lot of cpu time…)
IC. Jack master and timebase support is new in Hydrogen 0.9.4. Running Renoise as master works great here, as you already said. Running it as slave indeed causes a lot of problems. Looks like the beat times Hydrogen passes are somehow broken or unprecise. I will test and debug this and contact the Hydrogen devs. This does not seem to be a general problem with Jack but more a problem with Hydrogen.
Please use Hydrogen as Slave in the meanwhile. This anyway makes more sense?
Renoise as Master → works great, but still 1st line missed (in pattern loop mode), as it was with Hydrogen 0.9.4. Hydrogen doesn’t take tempo changes.
Hydrogen as Master → works great, but still 1st line missed too in Renoise (in pattern loop mode). Renoise doesn’t take tempo changes from Hydrogen.
It seems to be a pseudo jack transport implemented in Hydrogen 0.9.3.1, as tempo changes don’t affect jackdump slaves…
Also tested with Sooperlooper V-1.6.14 (sync to jack/host)
Renoise as master → works great, but still 1st line missed (in pattern loop mode), as it was with Hydrogen
Renoise as slave (enabled in Sooperlooper Prefs) → Renoise Crashes with a Segmentation Error as I enable “Become JackTime Master” in SooperLooper Prefs.
This bug is not hard to reproduce :
→ Starting a pattern loop with Renoise, as Master
→ Playing a loop in Sooperlooper (sync to jack/host), as slave
3 )-> changing SooperLooper Prefs as “Become JackTime Master”
4 )-> Renoise crashes with a segmentation error, or sometime freezes the pattern loop, with play button still active (but Renoise is still active), then desabling jack transport in the Prefs makes the Segmentation Crash Error
Renoise LOG> Application: Loading 'guitare-riff.xrns'...
Renoise LOG> MIDI: Using global MIDI actions from resources
Renoise LOG> Player: Constructing...
Renoise LOG> Player: Creating the slave threads...
Renoise LOG> Player: Start running...
Renoise LOG> GUI: Creating the Document GUI...
Renoise LOG> GUI: Successfully constructed
Renoise LOG> Application: Successfully loaded 'guitare-riff.xrns'.
Renoise LOG> Jack: Released Jack transport & timebase support...
Erreur de segmentation
``` .
Hydrogen as master does not really work. As said above, theres something fishy with the beat times it passes as master. Renoise seems to be the only Jack transport application which uses beat times for syncing right now, but we do rely on them being exact. I will contact the hydrogen devs to get this sorted out. Thats all I can do now. Sorry… I will also take a look at the Sooperlooper crash.
At the end this jack transport thing is a mess. So far it has caused more problems than doing something helpful and I’m not sure if we ever can make it ever 100% working. One problem is the architecture of Jack transport (no loop support, master and slave combined in one protocol), the other Renoise not being build around Jack. Basically we can not using Jacks time internally, but have to use it to check how and if we have to sync Renoise.
If we’re not getting this work reliably this is reason enough to remove it completely in upcoming releases?
Yes, should be maybe better to remove it completly, as it does not give satisfaction for now…
In an other way , Jakdump is still in development, the last release is from 4 days ago…
JACK 1.9.5 released
Submitted by letz on Mon, 2010-02-15 10:38.
Continuing the JACK2 serie.
- Dynamic choice of maximum port number.
- More robust sample rate change handling code in JackCoreAudioDriver.
- Devin Anderson patch for Jack FFADO driver issues with lost MIDI bytes between periods (and more).
- Fix port_rename callback : now both old name and new name are given as parameters.
- Special code in JackCoreAudio driver to handle completely buggy Digidesign CoreAudio user-land driver.
- Ensure that client-side message buffer thread calls thread_init callback if/when it is set by the client (backport of JACK1 rev 3838).
- Check dynamic port-max value. Fix JackCoreMidiDriver::ReadProcAux when ring buffer is full (thanks Devin Anderson).
- Josh Green ALSA driver capture only patch. When threads are cancelled, the exception has to be rethrown.
- Use a QUIT notification to properly quit the server channel, the server channel thread can then be 'stopped' instead of 'canceled'.
- Mario Lang alsa_io time calculation overflow patch.
- Shared memory manager was calling abort in case of fatal error, now return an error in caller.
- Change JackEngineProfiling and JackAudioAdapterInterface gnuplot scripts to output SVG instead of PDF.
Or simply hack Jack and submit our own proof concept Jack library to their CVS.
I think approaching Linux from this viewpoint is the strongest approach.
It’s open source anyway so why wait until others are doing things?
I’m not sure this is wise idea. The linux hardliners tend to look at commercially developed apps… differently.
Did anyone from the renoise dev team approach for instance Paul Davis (author of jack) and discuss the problems with him. If you’re able to start it of in a nice tone, he will be very warm and helpful. He’s very passionate about his software, very smart and for sure not some hacking script kiddie.
NB: I tried syncing ardour with renoise last night for a vocal session, but I also had the skipped-first-renoise-note-wehn-started-from-renoise-issue. What’s the status of that? Somehow I had the impression that it was fixed…
I did not really intended to give the idea to walz right over the original development team here, but more hook up and improve development.
Collaboration is always better and specially if the original author is willing to support, that is how things are getting done.
Yeah, “commercial”, well, on one side lots of Linux users would like a good equivalent of a commercial application on Linux yet not many are really willing to investigate some good time in it. Some times good stuff requires a little investment. It doesn’t have to cost a month salary though.
But if folks always stick to the idea that everything has to be available for free and the sourcecode has to be open, the development pace on many projects remain average to slow or projects eventually even die.
If i try to look up projects or tools on sourceforge, i see many projects that are either in initial state or Alpha and seemed to be abandoned years ago.
Open source is nice but does not offer warrants of productivity and usability.
