GrandOrgue

Hi David,

I assume that you're using the Windows version of GrandOrgue 0.2? Do
you still get distortion of that note if you reduce the organ
amplitude?

Kind regards,
GrahamG

On 12/30/11, David Santinoli <marauder@...> wrote:
>
> Hallo,
>   I'm experiencing an anomaly in the playback of the Stiehr-Mockers
> organ.  Namely, when playing the 4th A key on the "Cornett 5 rngs"
> stop, the sustain segment of the output sound is heavily distorced,
> audibly resembling a square wave.  (The attack and release are OK,
> however.)
>
> I've examined the corresponding sample file, i.e.
> jeux/Jeuxdorgues2_GrandOrgue/GOCornet/081-A.wav
> but it looks apparently OK, so I thought it might have something to do
> with the playback engine instead -- that's why I'm writing to the
> GrandOrgue list in addition to the Jeux maintainers.
>
> Thanks,
>  David
>
> ------------------------------------------------------------------------------
> Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
> infrastructure or vast IT resources to deliver seamless, secure access to
> virtual desktops. With this all-in-one solution, easily deploy virtual
> desktops for less than the cost of PCs and save 60% on VDI infrastructure
> costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
> _______________________________________________
> ourorgan-developers mailing list
> ourorgan-developers@...
> https://lists.sourceforge.net/lists/listinfo/ourorgan-developers
>

On Thu, Dec 29, 2011 at 11:36:48PM +0100, David Santinoli wrote:
>   I'm experiencing an anomaly in the playback of the Stiehr-Mockers
> organ.  Namely, when playing the 4th A key on the "Cornett 5 rngs"
> stop, the sustain segment of the output sound is heavily distorced,
> audibly resembling a square wave.  (The attack and release are OK,
> however.)

I tested stiehrrdc30a.organ with GO trunk without noticing any problem
for any A of "Cornet 5 rngs (C)".

md5sum of the wav file, as I don't know if there are different versions out there:
e8206bda974d224e995a6e850a84578d  jeuxdorgues2_hauptwerk/GOCornet/46-A4.wav

If it is caused by a bug in an older GO release, my personal recommendation
is upgraded to the GO version from svn trunk.

Regards,
Martin

Hi Martin,

Let's change the default appearance :)

If you need custom graphics let me know, I have a few custom ones from
my HW work.

On a similar subject, the .organ file contains a version number, i.e.
HauptwerkOrganFileFormatVersion=1.24

Would it be possible to add a different OrganFileFormatVersion, like

GrandOrgueFileFormatVersion=0.3

Then it would be possible to keep backward compatibility and add new
features that may be totally different. What do you think?

Kind regards,
GrahamG

On 12/27/11, Martin Koegler <martin.koegler@...> wrote:
> I have just commited the basis for custom enclosures - the drawing code
> now uses bitmaps, so that switching to custom grapics is easier.
>
> We can't change the bitmap size without maybe breaking some existing
> organs, but we could change the default apperance (Graham?).
>
> Regards,
> Martin
>
> ------------------------------------------------------------------------------
> Write once. Port to many.
> Get the SDK and tools to simplify cross-platform app development. Create
> new or port existing apps to sell to consumers worldwide. Explore the
> Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
> http://p.sf.net/sfu/intel-appdev
> _______________________________________________
> ourorgan-developers mailing list
> ourorgan-developers@...
> https://lists.sourceforge.net/lists/listinfo/ourorgan-developers
>

On Tue, Dec 27, 2011 at 09:51:58AM +0200, Graham Goode wrote:
> Let's change the default appearance :)
> 
> If you need custom graphics let me know, I have a few custom ones from
> my HW work.

The graphic size must be 46x61 with a place for a text line (7 pt font size)
and should fit in the existing layouts. Transparency is technical possible.

See src/grandorgue/images/Enclosure*.png - it's easy to change the number of graphics.
 
> On a similar subject, the .organ file contains a version number, i.e.
> HauptwerkOrganFileFormatVersion=1.24
> 
> Would it be possible to add a different OrganFileFormatVersion, like
> 
> GrandOrgueFileFormatVersion=0.3
> 
> Then it would be possible to keep backward compatibility and add new
> features that may be totally different. What do you think?

The value of this setting is ignored by GO, it just checks the presence of HauptwerkOrganFileFormatVersion.
We can add a GrandOrgueFileFormatVersion for informational purposes, but requiring it will break backward compatibility.

Regards,
Martin

On Tue, Dec 27, 2011 at 09:25:00AM +0100, Martin Koegler wrote:
> On Tue, Dec 27, 2011 at 09:51:58AM +0200, Graham Goode wrote:
> > Let's change the default appearance :)
> > 
> > If you need custom graphics let me know, I have a few custom ones from
> > my HW work.
> 
> The graphic size must be 46x61 with a place for a text line (7 pt font size)
> and should fit in the existing layouts. Transparency is technical possible.
> 
> See src/grandorgue/images/Enclosure*.png - it's easy to change the number of graphics.

I have added basic support for custom enclosures (including help updates). Some settings are described with 
a default value of implementation dependend. That means, that these defaults will probably be changed.
So if you use custom enclosures, better specify a value for these settings.

Regards,
Martin

On Tue, Dec 27, 2011 at 09:51:58AM +0200, Graham Goode wrote:
> If you need custom graphics let me know, I have a few custom ones from
> my HW work.

I'm working on custom manual/pedal support. 

I have look at HW package of Burea from Lars homepage.

I'm not sure, how the overlap between the sharp and natural keys is handled.

The mask could indicate, that space is divided into two regions: one fixed region for
the sharp key and one for the natural key - each key may only draw into its region.

------------

I guess, that we want to refresh the artwork for the manual/pedals in the long term too.


GO includes two sets of pedals:
* naturals: wood, sharps: black
* naturals: black, sharps: wood

GO includes 4 sets of manuals:
* naturals: white, sharps: black
* naturals: black, sharps: white
* naturals: wood, sharps: black
* naturals: black, sharps: wood

Is there any free artworks for pedals?

Regards,
Martin

Hi!


>
>I guess, that we want to refresh the artwork for the manual/pedals in the long term too.
>
>
>GO includes two sets of pedals:
>* naturals: wood, sharps: black
>* naturals: black, sharps: wood
>
>GO includes 4 sets of manuals:
>* naturals: white, sharps: black
>* naturals: black, sharps: white
>* naturals: wood, sharps: black
>* naturals: black, sharps: wood
>
>Is there any free artworks for pedals?


If you can tell me what exactly you'd like to have I can certainly go around and photograph pedals (and manuals) in a few different organs that can be reworked into the necessary images to form nice alternatives. Things like necessary angles, sizes etc would be good to know for the different shots.

Any other ideas for this?

Kind regards

Lars P

On Thu, Dec 22, 2011 at 08:58:49PM +0000, Lars Palo wrote:
> There has been some interest in getting more available ShortcutKeys on http://www.magle.dk/music-forums/14667-grandorgue-myorgan-stops-control.html.
> 
> The problem currently lies mostly in that EVT_KEY_DOWN is used in GOGUIPanelWidget.cpp event table, which always gives upper-case values for alphanumeric keys. If I change to EVT_CHAR on the other hand both upper and lower case is recognized (with proper changes in KeyConvert.h) but the Set toggle in OnKeyCommand(wxKeyEvent& event) method is lost...
> 
> Is this something we should care about changing? Or should present code and behaviour be kept for legacy reasons?

http://www.magle.dk/music-forums/14667-grandorgue-myorgan-stops-control.html#post144326

>From the control point of view, multiple events on one keyboard key are not useful. Consider your 
organ has an shift key and only half of the stop knobs.

The user wants GO to distingush key presses from different keyboards using a dirty hack (mapping to A and a).
I have doubts, that the fixed modifier key will work (http://blogs.msdn.com/b/michkap/archive/2005/11/17/492328.aspx).

For a clean solution, we will need read the raw input data using OS specific APIs and add a key matching system similar to
our MIDI matching system.

Regards,
Martin
PS: Is it OK, that each panel has it's own shortcuts?

Hi!


>From the control point of view, multiple events on one keyboard key are not useful. Consider your 
>organ has an shift key and only half of the stop knobs.


Ok, no problem, I accept that it's more important that a stop can be activated immediately on the keyboard without any modifier keys. I've more or less abandoned using the keyboard myself while playing anyway... My FCB1010 provides me with enough options at the moment.


>The user wants GO to distingush key presses from different keyboards using a dirty hack (mapping to A and a).
>I have doubts, that the fixed modifier key will work (http://blogs.msdn.com/b/michkap/archive/2005/11/17/492328.aspx).
>
>For a clean solution, we will need read the raw input data using OS specific APIs and add a key matching system similar to
>our MIDI matching system.


It's very harly worth the trouble, I think. It's much more flexible to use MIDI messages instead. True stopboard panels with controls that send MIDI messages is both more organ-like and nicer to use IMO.


>PS: Is it OK, that each panel has it's own shortcuts?
>


It can easily lead to confusion I guess, and I doubt that it's a feature that will be very much used. But maybe someone will find a use case for it.

A more sensible improvement could perhaps be that at some point in the future the user can set the shortcut keys for controls from within the GUI instead of having to edit the ODF manually... Just an idea.

Kind regards

Lars P

On Tue, Dec 20, 2011 at 10:41:51PM +0000, Lars Palo wrote:
> In the enclosed text file some more temperaments that I think should be included are presented.

I commited your data.
 
> I certainly hope that the random detuning will be a feature that can be switched on and off! I'd even like to have both the options of having one random detuning at loading and another (also customizable) that can be happening while playing (even if I'm really very suspicious about that as a feature...). 

It's wired to the randomize option in the settings dialog.

Regards,
Martin

On Tue, Dec 20, 2011 at 02:54:22PM +0000, Lars Palo wrote:
> Perhaps I understand things wrongly, but from the documentation I understand that the width of the clickable region for a button object should be decided by the parameter MouseRectWidth=, which should default to Width (which in itself should defalult to bitmap width). As far as I can see this doesn't happen, instead one gets a small clickable square that seems to be decided from the Height instead. (I have a rectangular bitmap as a stop button in this case and the text layout seems to understand the width correctly...)
> 
> Most likely I could override the bug by specifying the exact MouseRectWidth I want, but shouldn't it (indirectly) take it's width from the bitmap? (I encountered this when I created a new panel with custom graphics and layout)

Mouse regions is per default a circle - set the radius to 0.
 
> P.S. Is there a way to specify that a custom image should be rotated?

No. 

Regards,
Martin
PS: Is there a rotation feature in HW?

Martin,

Can you explain what you mean by "the factor is only adjusted while jumping to the next audio section".
I was thinking it would be easier to add a random offset in GOrgueTemperamentCent::GetOffset.

I still can't use your patches and I would be happy if they were submitted so that we can evaluate and possibly modify.

JL

-----Original Message-----
From: Martin Koegler [mailto:martin.koegler@...] 
Sent: samedi 17 décembre 2011 16:32
To: ourorgan-developers@...
Subject: [Ourorgan-developers] GO patches

I have commited the initial portaudio code + some bug fixes.

5-17 are the last version of temperament patch rebased to trunk.
There have been lots of dicussion and it would be nice to summarize from the ODF/technical point of view, how the support in GO should look like, so that I can start to adjust my patches.

I'm searching data about further temperaments (name + offsets in cent), so that I can add them too.

18 implements a randmoized +/- 2 cent tuning, as suggest be Lars. To keep the overhead minimal, the factor is only adjusted while jumping to the next audio section. It is wired to the unused randomized option in the setting dialog.
The cent number is 2.0 in 2.0 / 1200.0, if somebody wants to try out different detunings.
I don't want to judge, if it this is an sound improvement or not.

19 prepares GO for more output sample rates. Adding further sample rates just mean to add the number to the dropdown box.
After this is commited, http://sourceforge.net/tracker/?func=detail&aid=2988560&group_id=264596&atid=1333887
should be solved (Do we really want to add 96000 for output devices too?)

20 improves the GUI by always reporting, if opening the sound failed.

21 changes README to recommend mingw-w64 instead of mingw. 

5-18 are on hold, until a consensus about them has been reached.

I intent to commit 19-21, if there is no opposition.

Regards,
Martin

On Sat, Dec 17, 2011 at 11:14:47PM +0000, Derouineau, Jean-Luc wrote:
> Can you explain what you mean by "the factor is only adjusted while jumping to the next audio section".
> I was thinking it would be easier to add a random offset in GOrgueTemperamentCent::GetOffset.

The temperament code is only run after loading or after changing the temperaments (so the calculations
can be more expensive).
Putting it there would mean, that the offset is fixed until the next temperament change.
Additionally, the randomization must be implemented in more than one place 
and in my option, it does not fit in this class.

My implementation generates a new offset at:
* start playing of the attack phase
* switching to the loop phase
* jumping in the loop backward
* switching to the release phase

This way, the offset is changed on the fly while keeping the overhead minimal.

> I still can't use your patches and I would be happy if they were submitted so that we can evaluate and possibly modify.

What patches should I apply?

Regards,
Martin

On Sat, Dec 17, 2011 at 11:14:47PM +0000, Derouineau, Jean-Luc wrote:
> I still can't use your patches and I would be happy if they were submitted so that we can evaluate and possibly modify.

I spent some time on bugfixing and they are working enough, so that I have commited them [includings Nicks Audiosection
rename patches] => GO trunk support detuning + temperaments.

I tested them with Pibrac and St.StAugustines [24bit HW samples].

After fixing the some bugs in GO and adding the HarmonicNumber to the none 8' stops, I got a useable result.

I also annotated Pibrac with the HarmonicNumber [the special case Plein-Jeu 3 got 48 and sounded OK].
Vox celesits was tuned to normal stop, as I specified no Pitch correction.
Doublette 2' sounded totally detuned. Clairon 4' and Flûte Harmonique 8' were also not OK.

Adding further temperaments is easy (see attached patch for something like mean tone).

OK with commited the patch suggesting mingw-w64 instead of mingw?

Regards,
Martin
PS: I noticed, that our release alignment code causes clicks, if a large latency is in use.

On Sat, Dec 17, 2011 at 01:28:17PM +0000, Derouineau, Jean-Luc wrote:
> Seems I am missing some files.
> Is this necessary to download a SDK for Portaudio?
> 
> c:\mingw32\bin\../lib/gcc/mingw32/4.6.1/../../../../include/objidl.h:1439:86: er
> ror: unknown type name 'IUnknown'
> c:\mingw32\bin\../lib/gcc/mingw32/4.6.1/../../../../include/objidl.h:1445:71: er
> ror: unknown type name 'IUnknown'
> c:\mingw32\bin\../lib/gcc/mingw32/4.6.1/../../../../include/objidl.h:1446:70: er
> ror: unknown type name 'IUnknown'
> c:\mingw32\bin\../lib/gcc/mingw32/4.6.1/../../../../include/objidl.h:1450:91: er
> ror: unknown type name 'IUnknown'
> c:\mingw32\bin\../lib/gcc/mingw32/4.6.1/../../../../include/objidl.h:1452:92: er
> ror: unknown type name 'IUnknown'
> C:\GO\trunk\src\portaudio\hostapi\wasapi\pa_win_wasapi.c:150:27: fatal error: sd
> kddkver.h: No such file or directory
> compilation terminated.
> mingw32-make[2]: *** [lib/portaudio/CMakeFiles/PortAudio.dir/hostapi/wasapi/pa_w
> in_wasapi.c.obj] Error 1
> mingw32-make[1]: *** [lib/portaudio/CMakeFiles/PortAudio.dir/all] Error 2
> mingw32-make: *** [all] Error 2

You are facing a problem with the WASAPI backend. This backend can be disabled (-DRTAUDIO_USE_WASAPI=OFF as cmake parameter).

WASAPI requires newer APIs - but the non MS SDKs are usually a little bit outdated.

I merged together free headers to compile WASAPI on a recent mingw-w64 [timestamp: 20110523].
Older mingw ship ole headers, which are incompatible with my additions [error message: unknown type name 'IUnknown'].

Portaudio itself includes a set of header for mingw too (including files with MS copyright):
http://portaudio.com/trac/browser/portaudio/trunk/src/hostapi/wasapi/mingw-include

Maybe they work better with older compilers [delete the content of src/portaudio/hostapi/wasapi/wine-include 
and replace the content in src/portaudio/hostapi/wasapi/mingw-include].

I use for my windows build currently mingw-w64 (the precompiled ubuntu packages):
http://sourceforge.net/projects/mingw-w64/
mingw-w64 seems to be the better maintained project than mingw and has no requirement for an extra DLL.
It provides a 32 bit and a 64 bit compiler.

On this list, tdm gcc has been recommended some time ago. According to their webpage (http://tdm-gcc.tdragon.net/start)
they offer two flavors: TDM (= mingw build) and TDM64 (= mingw-w64 build).

Using a new TDM64 or mingw-w64 is probably the best solution to build WASAPI.

Regards,
Martin

I could get an exe by turning WASAPI OFF.
It get 5 more output interfaces:
MME: IDT Audio
MME: Microsoft Sound Mapper - output
Windows Directsound: IDT Audio
Windows DirectSound: Primary Sound Driver
Windows WDM-KS: IDT Audio

WDM-KS generates a GO error when selected: "Sample format not supported" and then no sound is produced by GO if when selecting another interface.

JL

-----Original Message-----
From: Martin Koegler [mailto:martin.koegler@...] 
Sent: samedi 17 décembre 2011 15:31
To: GrandOrgue Developers List
Subject: Re: [Ourorgan-developers] GO audio output library

On Sat, Dec 17, 2011 at 01:28:17PM +0000, Derouineau, Jean-Luc wrote:
> Seems I am missing some files.
> Is this necessary to download a SDK for Portaudio?
> 
> c:\mingw32\bin\../lib/gcc/mingw32/4.6.1/../../../../include/objidl.h:1439:86: er
> ror: unknown type name 'IUnknown'
> c:\mingw32\bin\../lib/gcc/mingw32/4.6.1/../../../../include/objidl.h:1445:71: er
> ror: unknown type name 'IUnknown'
> c:\mingw32\bin\../lib/gcc/mingw32/4.6.1/../../../../include/objidl.h:1446:70: er
> ror: unknown type name 'IUnknown'
> c:\mingw32\bin\../lib/gcc/mingw32/4.6.1/../../../../include/objidl.h:1450:91: er
> ror: unknown type name 'IUnknown'
> c:\mingw32\bin\../lib/gcc/mingw32/4.6.1/../../../../include/objidl.h:1452:92: er
> ror: unknown type name 'IUnknown'
> C:\GO\trunk\src\portaudio\hostapi\wasapi\pa_win_wasapi.c:150:27: fatal error: sd
> kddkver.h: No such file or directory
> compilation terminated.
> mingw32-make[2]: *** [lib/portaudio/CMakeFiles/PortAudio.dir/hostapi/wasapi/pa_w
> in_wasapi.c.obj] Error 1
> mingw32-make[1]: *** [lib/portaudio/CMakeFiles/PortAudio.dir/all] Error 2
> mingw32-make: *** [all] Error 2

You are facing a problem with the WASAPI backend. This backend can be disabled (-DRTAUDIO_USE_WASAPI=OFF as cmake parameter).

WASAPI requires newer APIs - but the non MS SDKs are usually a little bit outdated.

I merged together free headers to compile WASAPI on a recent mingw-w64 [timestamp: 20110523].
Older mingw ship ole headers, which are incompatible with my additions [error message: unknown type name 'IUnknown'].

Portaudio itself includes a set of header for mingw too (including files with MS copyright):
http://portaudio.com/trac/browser/portaudio/trunk/src/hostapi/wasapi/mingw-include

Maybe they work better with older compilers [delete the content of src/portaudio/hostapi/wasapi/wine-include 
and replace the content in src/portaudio/hostapi/wasapi/mingw-include].

I use for my windows build currently mingw-w64 (the precompiled ubuntu packages):
http://sourceforge.net/projects/mingw-w64/
mingw-w64 seems to be the better maintained project than mingw and has no requirement for an extra DLL.
It provides a 32 bit and a 64 bit compiler.

On this list, tdm gcc has been recommended some time ago. According to their webpage (http://tdm-gcc.tdragon.net/start)
they offer two flavors: TDM (= mingw build) and TDM64 (= mingw-w64 build).

Using a new TDM64 or mingw-w64 is probably the best solution to build WASAPI.

Regards,
Martin


------------------------------------------------------------------------------
Learn Windows Azure Live!  Tuesday, Dec 13, 2011
Microsoft is holding a special Learn Windows Azure training event for 
developers. It will provide a great way to learn Windows Azure and what it 
provides. You can attend the event by watching it streamed LIVE online.  
Learn more at http://p.sf.net/sfu/ms-windowsazure
_______________________________________________
ourorgan-developers mailing list
ourorgan-developers@...
https://lists.sourceforge.net/lists/listinfo/ourorgan-developers

On Sat, Dec 17, 2011 at 03:44:39PM +0000, Derouineau, Jean-Luc wrote:
> I could get an exe by turning WASAPI OFF.
> It get 5 more output interfaces:
> MME: IDT Audio
> MME: Microsoft Sound Mapper - output
> Windows Directsound: IDT Audio
> Windows DirectSound: Primary Sound Driver
> Windows WDM-KS: IDT Audio

Are Windows Directsound and MME working for you?

Does ASIO compile?

If you compile with ASIO, there should see your devices two times (one time RtAudio, one time PortAudio).
If you only see them one time, maybe they are mapped to the same name. In that case, please edit src/grandorgue/GOrgueSound.cpp and
replace in the line [at the end of GOrgueSound::GOrgueSound]:
                wxString name = wxGetTranslation(wxString::FromAscii(api->name)) + wxString(wxT(": ")) + wxString::FromAscii(info->name);

wxString(wxT(": ")) with a different string (eg. wxString(wxT(":xxxx "))).
This way, portaudio devices will definitly be map to a different name.

> WDM-KS generates a GO error when selected: "Sample format not supported" and then no sound is produced by GO if when selecting another interface.

Nice to know, that WDM-KS detects devices. I'll start looking at WDM-KS and WASAPI problems, after all other portaudio issues are solved.

Regards,
Martin

Indeed the port audio was mapped under the same name.

Both are working.
rtaudio version allocates 512 samples for the buffer and the displayed latency is 13 ms
portaudio version allocates 768 samples for the buffer and the displayed latency is 18 ms

JL

-----Original Message-----
From: Martin Koegler [mailto:martin.koegler@...] 
Sent: samedi 17 décembre 2011 17:53
To: GrandOrgue Developers List
Subject: Re: [Ourorgan-developers] GO audio output library

On Sat, Dec 17, 2011 at 03:44:39PM +0000, Derouineau, Jean-Luc wrote:
> I could get an exe by turning WASAPI OFF.
> It get 5 more output interfaces:
> MME: IDT Audio
> MME: Microsoft Sound Mapper - output
> Windows Directsound: IDT Audio
> Windows DirectSound: Primary Sound Driver
> Windows WDM-KS: IDT Audio

Are Windows Directsound and MME working for you?

Does ASIO compile?

If you compile with ASIO, there should see your devices two times (one time RtAudio, one time PortAudio).
If you only see them one time, maybe they are mapped to the same name. In that case, please edit src/grandorgue/GOrgueSound.cpp and
replace in the line [at the end of GOrgueSound::GOrgueSound]:
                wxString name = wxGetTranslation(wxString::FromAscii(api->name)) + wxString(wxT(": ")) + wxString::FromAscii(info->name);

wxString(wxT(": ")) with a different string (eg. wxString(wxT(":xxxx "))).
This way, portaudio devices will definitly be map to a different name.

> WDM-KS generates a GO error when selected: "Sample format not supported" and then no sound is produced by GO if when selecting another interface.

Nice to know, that WDM-KS detects devices. I'll start looking at WDM-KS and WASAPI problems, after all other portaudio issues are solved.

Regards,
Martin

------------------------------------------------------------------------------
Learn Windows Azure Live!  Tuesday, Dec 13, 2011
Microsoft is holding a special Learn Windows Azure training event for 
developers. It will provide a great way to learn Windows Azure and what it 
provides. You can attend the event by watching it streamed LIVE online.  
Learn more at http://p.sf.net/sfu/ms-windowsazure
_______________________________________________
ourorgan-developers mailing list
ourorgan-developers@...
https://lists.sourceforge.net/lists/listinfo/ourorgan-developers