Recent Posts

1

Help and Questions / Re: OpenMPT always behind VST windows

« Last post by Exhale on Yesterday at 02:47:00 »

I can imagine many reasons to want the vst interfaces open for extended periods of time... Many of the most useful scenarios I can think of would be in live performance.

Maybe open vsts could minimize to an even more compact version of the double click (the X, the minimize - and maybe a millimeter to pull on for moving it around.

2

Help and Questions / Re: OpenMPT always behind VST windows

« Last post by LPChip on January 27, 2020, 21:10:29 »

Honestly, I would not want OpenMPT to be in FRONT of my VSTi's, given that the VSTi windows don't have a taskbar entry. I would have to minimize my OpenMPT to access the VSTi's. I'd rather close them once I'm done with them, given that I don't use them most of the time, only when I create a sound and when I tweak during mixing/mastering. During composing I don't need them, so they are closed.

Maybe you would want to look into your workflow? Why do you need these windows open all the time? Is it because opening/closing is difficult? Could it be that your way of opening/closing is not the best way?

3

Help and Questions / Re: OpenMPT always behind VST windows

« Last post by RG (aka AUDIOMONSTER) on January 26, 2020, 21:27:05 »

Yes, indeed, but I just wanted not to have to minimize the VSTs, so they stay on my sight. OK then, I'll try other options.

4

Help and Questions / Re: OpenMPT always behind VST windows

« Last post by LDAsh on January 26, 2020, 17:56:47 »

As a workaround, there are a couple of programs out there like AlwaysOnTop (https://www.labnol.org/files/always-on-top.zip) and there is another one that can apparently make any window semitransparent but I can't remember what it's called (www.lukepaynesoftware.com/projects/peek-through/) ?...  You might also look into "multi-desktop" software of which I'm sure there are freeware alternatives. - (http://windowspager.sourceforge.net/)

5

Help and Questions / Re: OpenMPT always behind VST windows

« Last post by Saga Musix on January 26, 2020, 17:15:30 »

OpenMPT's behaviour is (and always has been, there was no change) similar to how most DAWs handle plugin windows - and it would very easy to 'lose' a plugin window if it ends up behind other windows (you would potentially have to minimize all other open document windows).
However, what might be helpful for you is to double-click the plugin window's title bar - this will minimize the plugin window so that it only consists of the title and menu bar, saving some precious screen space.

6

Help and Questions / Re: OpenMPT always behind VST windows

« Last post by RG (aka AUDIOMONSTER) on January 26, 2020, 16:57:47 »

By the way, I'm wondering if it's always been like this, in previous releases. I have a doubt.

7

Help and Questions / OpenMPT always behind VST windows

« Last post by RG (aka AUDIOMONSTER) on January 26, 2020, 16:46:25 »

Hi there,

It would be nice to be able to have the OpenMPT window IN FRONT of VST windows, when simply clicking on it, instead of always beeing behind them.

Indeed, that would be more easy to pass from one VST window to OpenMPT window, instead of reducing or moving the VST windows.

Currently, VST windows are always on top, which can be pretty annoying when working on a single not so big screen.

Cheers ;-)

8

Development Corner / Re: How does OpenMPT's audio pipeline work?

« Last post by Saga Musix on January 24, 2020, 20:55:16 »

libopenmpt doesn't use callbacks (you simply call into the library to get audio), the rest looks correctly to me.

9

Development Corner / Re: How does OpenMPT's audio pipeline work?

« Last post by nyanpasu64 on January 24, 2020, 20:47:47 »

"libopenmpt does not talk directly to an output device, but merely exposes a callback api with no knowledge of locks or portaudio. (OpenMPT allows simple edits to patterns without locks! Complex edits require locking though.) libopenmpt can be called via ffmpeg or foobar2000, which have their own non-speaker output mechanisms."

Is this correct? I'm going to design my API similarly, with the actual synth being unaware of locks.

The document storage will use a fancy double-buffered page-flip mechanism so the audio thread will always have at least 1 of 2 documents not locked by the GUI. The atomic operations were complicated to get right, and I had to read https://www.hpl.hp.com/techreports/2012/HPL-2012-68.pdf to make sure. I still haven't actually implemented editing... probably should add a unit test for that once I get the editing API down :S

10

Development Corner / Re: libopenmpt get separated audio data for each channel

« Last post by bass on January 22, 2020, 11:13:50 »

OK, the ticket is from 2017, so it doesn't seem, that this feature will come soon...
Thank you anyway, I'll check the status of the ticket from time to time. Perhaps I can find another library with this feature.