Midi instrument detuned

#1

After re-opening an Ardour session recently one of my midi tracks seems to have down-tuned by about a tone.

Nothing in the session has changed, I saved and closed it, when I re-opened one of my midi synth instruments plays back everything roughly a tone down. If I raise all the midi notes by a tone it gets roughly back into tune, but is still not quite correct and doesn’t sound like it did previously.

The instrument I’m using is Surge, I’ve tried deleting and re-inserting it, I’ve even created an entirely new track and added a new instance of Surge, it still has the same problem, it plays everything roughly a tone below where it should be.

I’ve seen reference in these forums to this possibly being caused by sample rate mismatches, but everything I have is running at 48kHz.

I have another instance of Surge running on a different track in the session which is playing back normally, it only appears to be on this particular track and on any new instances of Surge I create.

Frustratingly it’s not an exact tone out so I haven’t managed to tweak it to get it back in tune.

Any ideas?

Ardour 6.9
Surge 1.7

#2

How have you established that? What OS do you use? What backend?

#3

I’m using Ubuntu Studio 20.04.3, with alsa and Jack (1.9.12).

Ardour shows session as 48kHz, Qjackctl shows 48kHz - anything else I should check?

I have a number of other midi tracks and instruments in the session that haven’t been affected in the same way and none of the audio tracks have been affected either.

#4

I’ve just added a new midi track and a new instance of surge and it’s now playing back in tune, so I think it might just be that specific midi track. Any idea what might cause that to happen?

#5

replied too soon, it played in tune once, as soon as I stopped and restarted playback it’s detuned.

#6

In case jack, the actual hardware samplerate [1]. jackd can silently fall back to the nearest available without informing anyone. But usually that happens with 44.1k → 48k for soundcards that only support 48kHz. So it is not likely an issue here.

Aha, that is a good clue. So it is specific to a synth and/or track.

MIDI pitch-bend comes to mind, or perhaps a CC that sets surge’s tuning. Ardour replays MIDI events when the session is loaded. Check "A"utomation in the track header of the MIDI track and show MIDI “Bender” controls.

Without restarting Ardour, can you load a different synth plugin and see if that also has the issue?

–

[1] in a terminal window run

cd /tmp && wget https://community.ardour.org/files/adevices.sh && bash ./adevices.sh

That lists all soundcards, their current settings and applications using them, etc.

#7

Thanks Robin

So I’ve double-checked and there’s definitely no automation of any kind on either of the midi tracks this is happening on (I’ve just added a new midi track with a new instance of Surge and it’s happening on that too).

I’ve then added another new midi track and added the MDA Piano instrument and that plays in tune, so it does seem like it’s specific to Surge, but like I say, I have another 2 instances of Surge in the session that are playing fine.

The session is larger than most others I’ve created in the past. I’ve got 6 midi tracks, but 2 of those are fanned out drum tracks (drumgizmo and geonkick) and I have multiple plugins across about 26 audio tracks and busses - my pc is truggling a bit if I’m honest. I don’t know if that might be causing issues.

Part I: ALSA
Advanced Linux Sound Architecture Driver Version k5.4.0-90-lowlatency.

Card 0 (PCH):
  * Playback Device 0 (ALC1220 Analog):
    - Subdevice 0 (hw:PCH,0,0):
      closed

  * Playback Device 1 (ALC1220 Digital):
    - Subdevice 0 (hw:PCH,1,0):
      closed

  * Recording Device 0 (ALC1220 Analog):
    - Subdevice 0 (hw:PCH,0,0):
      closed

  * Recording Device 2 (ALC1220 Alt Analog):
    - Subdevice 0 (hw:PCH,2,0):
      closed

Card 1 (U192k):
  * Playback Device 0 (USB Audio):
    - Subdevice 0 (hw:U192k,0,0):
      used by: jackdbus (PID 2944)
      access: MMAP_INTERLEAVED
      format: S32_LE
      subformat: STD
      channels: 4
      rate: 48000 (48000/1)
      period_size: 4096
      buffer_size: 8192

  * Recording Device 0 (USB Audio):
    - Subdevice 0 (hw:U192k,0,0):
      used by: jackdbus (PID 2944)
      access: MMAP_INTERLEAVED
      format: S32_LE
      subformat: STD
      channels: 4
      rate: 48000 (48000/1)
      period_size: 4096
      buffer_size: 8192

Card 2 (NVidia):
  * Playback Device 3 (HDMI 0):
    - Subdevice 0 (hw:NVidia,3,0):
      closed

  * Playback Device 7 (HDMI 1):
    - Subdevice 0 (hw:NVidia,7,0):
      closed

  * Playback Device 8 (HDMI 2):
    - Subdevice 0 (hw:NVidia,8,0):
      closed

  * Playback Device 9 (HDMI 3):
    - Subdevice 0 (hw:NVidia,9,0):
      closed

  * Playback Device 10 (HDMI 4):
    - Subdevice 0 (hw:NVidia,10,0):
      closed

Card 3 (WEBCAM):
  * Recording Device 0 (USB Audio):
    - Subdevice 0 (hw:WEBCAM,0,0):
      closed

========================================
Part II: jack processes
   1605 ?        Ss     0:00 /usr/bin/python3 -u /usr/bin/autojack
   2145 ?        Ss     0:00 /usr/bin/python3 -u /usr/bin/autojack
   2944 ?        SLsl   0:05 /usr/bin/jackdbus auto
========================================
Part III: jack-dbus config
--- status
started
--- get selected driver
alsa
--- get driver parameters (type:isset:default:value)
              device: ALSA device name (str:set:hw:0:hw:U192k,0,0)
             capture: Provide capture ports.  Optionally set device (str:set:none:none)
            playback: Provide playback ports.  Optionally set device (str:set:none:none)
                rate: Sample rate (uint:set:48000:48000)
              period: Frames per period (uint:set:1024:4096)
            nperiods: Number of periods of playback latency (uint:set:2:2)
               hwmon: Hardware monitoring, if available (bool:set:False:False)
             hwmeter: Hardware metering, if available (bool:set:False:False)
              duplex: Provide both capture and playback ports (bool:set:True:True)
            softmode: Soft-mode, no xrun handling (bool:set:False:False)
             monitor: Provide monitor ports for the output (bool:set:False:False)
              dither: Dithering mode (char:set:n:n)
          inchannels: Number of capture channels (defaults to hardware max) (uint:notset:0:0)
         outchannels: Number of playback channels (defaults to hardware max) (uint:notset:0:0)
              shorts: Try 16-bit samples before 32-bit (bool:set:False:False)
       input-latency: Extra input latency (frames) (uint:notset:0:0)
      output-latency: Extra output latency (frames) (uint:notset:0:0)
         midi-driver: ALSA MIDI driver (str:set:none:seq)
--- get engine parameters (type:isset:default:value)
              driver: Driver to use (str:set:dummy:alsa)
                name: Server name to use. (str:notset:default:default)
            realtime: Whether to use realtime mode. (bool:set:True:True)
   realtime-priority: Scheduler priority when running in realtime mode. (sint:notset:10:10)
           temporary: Exit once all clients have closed their connections. (bool:notset:False:False)
             verbose: Verbose mode. (bool:set:False:False)
      client-timeout: Client timeout limit in milliseconds. (sint:set:0:500)
        clock-source: Clocksource type : c(ycle) | h(pet) | s(ystem). (uint:notset:0:0)
            port-max: Maximum number of ports. (uint:notset:2048:2048)
    replace-registry: Replace shared memory registry. (bool:notset:False:False)
                sync: Use server synchronous mode. (bool:notset:False:False)
   self-connect-mode: Self connect mode. (char:notset: : )
       slave-drivers: Slave drivers to use (str:notset::)
1 Like
#8

So the soundcard is set correctly.

Surge does have a “master-tune” control, but replacing the surge instance should reset that.

Now that you have solved it by replacing the whole MIDI track, this issue will likely remain a mystery.

#9

Hey,
I’m actually not sure the problem is declared solved, but one idea might be : do you have multiple versions of Surge installed (as in, maybe LV2 + VST) and available to Ardour?

If that’s the case, you might find that perhaps one version is not happy and the other is alright (I think I heard someone say that the LV2 version was troublesome, but don’t uqote me on that).

In any case, you should also be able to determine whether the trouble originates from the plugin or your patch, making a save of your offending track Patch and loading it up on another “functional” track, after duplicating it (maybe after having made a full backup of your session, just in case - if your computer is lagging behind then I’d take no chances).

Edit: you could also true loading the offending patch in a new session, to see if it’s still detuned when alone with your computer resources.

Or maybe I misread and you have, indeed solved the problem?

#10

Hi hellsend

It’s not exactly solved but I did seem to narrow it down to a load problem for my PC. With the removal of some tracks from the session that I no longer needed, I was able to get it to playback in tune long enough to complete an export. The fact that the problem only occurred after a certain period of time and was mitigated with the removal of tracks suggested to me that it was a performance issue rather than a specific problem with the synth, the session or Ardour itself.

I’m not sure if anyone else has encountered similar issues, it does seem an odd behaviour.

#11

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.