Just stumblin' over this golden oldie of a thread and thought I'd pitch in my 2 cents. Back in the day, you suggested Modartt might want to team up with other digital organ builders, right? Well, heck, why not? They've got a kickass piece of software, no doubt. And, who knows, this collab could be the next big thing.

But, here's a hot take: how about they not only collab but also use some nifty local SEO strategies to get the word out? Found this sick site, https://crowdo.net/local-seo, that's all about boosting local visibility. Could be a game-changer! And, get this, Modartt's been doing some innovating of their own. They've got Pianoteq for iOS now.

Interesting modules for the conversion of old organ consoles are offered by a Polish company..
https://www.midi-hardware.com/index.php...n=products

Just a quick comment on the Polish modules.

I have another hobby: pinball machines, both virtual and physical. I don't own one, but follow forums and groups with owners of real machines all the way back from the electromechanical era up to today. I see often topics about failing PCB boards from the 80's and 90's, battery leaks, acid damage, circuit problems, soldering, you name it. Regarding converted organ consoles, there is absolutely no guarantee a circuit board from will last more than 20 years and we don't know if the Polish company will even exist that long. For a hobbyist and home organ owner they could be interesting, for a church I absolutely would not recommend, unless the organist is good at soldering and fixing stuff. Alternatively, I think support from a local company would be needed.
PS They've got a nice Facebook page: https://www.facebook.com/midihardware

Lew,

Good luck with your project. I hope you design something good. I just experimented with my Launchpad to find something with physical buttons that won't need a screen and thought that Modartt could put together a bundle.

For my needs, sadly the launchpad doesn't offer what I need, so I'm going purely custom electronics through a developer. If you're looking though for an expanded surface to fully control organteq, go to www.yaeltex.com. I think I've shared in a post some designs for surfaces but could always upload a few updates for other users. I'm not going that direction on this build, but thought from a developer spec, these options are viable.

lew

Good luck with your project. I hope you design something good. I just experimented with my Launchpad to find something with physical buttons that won't need a screen and thought that Modartt could put together a bundle.

I forgot...
If Modartt can secure a deal with some conservatory with a manuals+pedals+Organteq bundle, that could open the way to more and more deals. I guess that in Orthodox Eastern Europe, organs are relatively scarce, however there is a big interest in organ music. Can you imagine a practice room with a couple of setups side by side powered by hidden mini-PCs?

YES!!!!! Perfect!

What if Modartt were to provide an OEM license for organ builders who apply to become suppliers of the software, so that an installation is already licensed, all the end user has to do is register the product to receive updates, etc. as these systems would effectively be headless in design.

It's funny you talking about this, I'm in the process of a console design still on going for my own work and things are starting to get interesting.

lew

lewisalexander2020 wrote:

What if, just as a thought, what about an app for iOS as an example which could work as a programmer resource for organteq to provide an accessible environment for voicing, saving particular functions, etc, or if not an app, why not look at an example of compiling code for the various available controls, midi CC's available, etc and produce a control surface whic would allow say, per stop voicing, accessing particular parameters such as preset creation, etc.

one area which I'm not sure if it's available, is the ability to save a complete preset via midi CC, that said however it requires keyboard entry to create a file name, that could be bypassed and instead just create a generic data name per preset to navigate through sequence. there's midi assigns for preset up / down, etc so that's good, also midi assigns for the layers of general pistons.

lew

Lew,

I seem to have been running around interlocking rabbit holes, with this question, like some demented character trapped in an Escher drawing. There are a number of kludgy solutions for automatically providing a user with a new, automatically generated preset file name that advances either numerically, or according to time stamp. However, I will admit that they all smell of the lamp and are particularly cumbersome to use. Every other function one would care to use, and a few I hadn’t even thought about, seem to be controllable via a midi CC, apart from the ability to name and save a new preset, which is the function we are looking for.

Practically, this is a aspect of the functionality, that would easiest provided by the developers at Modartt. The user would be given the option of automatically generating a new preset file in their “My Presets” with the format

    <user determined preset name>_<current datestamp_current timestamp>.fxp

The desired configuration of Organteq could then be automatically saved and named by either pressing the designated keyboard shortcut, or by activating a predefined midi CC. Each time a preset is automatically saved it is assigned a unique filename, courtesy of the current datestamp and timestamp in the name. It would also be useful to have the ability to save these presets to a sub-folder of “My Presets”, so that presets associated with a particular project could be automatically assigned to their own project folder. This would allow preset combinations to saved “on the fly” whilst tweaking the organ for that special, perfect sound.

A user would still have the ability to save a new preset in the normal way, by typing “Ctrl + Shift + T” and by manually entering a unique name for the preset and then saving. The solution, suggested above, could be used to capture that fleeting “Oh, that sounds nice!” moment without having to think about it and pausing the creative flow.

If you are looking for “a programmer resource for Organteq to provide an accessible environment” then you might want to check out JUCE:

    https://juce.com/

which has the dual advantage of being free for personal use (assuming you are not making more than $50k per annum from your musical design work) and that Modartt use JUCE to construct both Pianoteq and Organteq, and it is always easier to work in the same programming environment. It has been a while since I’ve had to peak inside compiled binary programs and also look at linked libraries, but you can always come up with some interesting information, as, for example, the use of JUCE functions in the program. The utilisation of JUCE is also mentioned in

https://www.linuxjournal.com/content/pi...uct-review

and one reference in the Forum. I assume that this is commonly known, but I hadn’t come across it until I went poking around. However, I’ve usually found it easier to convince developers of the needfulness of a new tweak, if I can point to how their current programming environment already supports the required functionality.

The JUCE website has some tantalising projects in its tutorials, which may give you some ideas on how to approach the interfaces you want to construct. I am not a programmer, but the site has given me some thoughts on how to construct applications I want, even if I don’t particularly want to have to write the code for them. However, the programming interface seems to be a click and insert the relevant code or plugins, so even my woeful coding skills may not be an issue, though I am not holding my breath.

Something more to read and think on, I suppose, in our “free” time.

Michael

BOB ON! Absolutely BOB ON!. That'll do nicely.

What if, just as a thought, what about an app for iOS as an example which could work as a programmer resource for organteq to provide an accessible environment for voicing, saving particular functions, etc, or if not an app, why not look at an example of compiling code for the various available controls, midi CC's available, etc and produce a control surface whic would allow say, per stop voicing, accessing particular parameters such as preset creation, etc.

one area which I'm not sure if it's available, is the ability to save a complete preset via midi CC, that said however it requires keyboard entry to create a file name, that could be bypassed and instead just create a generic data name per preset to navigate through sequence. there's midi assigns for preset up / down, etc so that's good, also midi assigns for the layers of general pistons.

lew

Lew,

I seem to have been running around interlocking rabbit holes, with this question, like some demented character trapped in an Escher drawing. There are a number of kludgy solutions for automatically providing a user with a new, automatically generated preset file name that advances either numerically, or according to time stamp. However, I will admit that they all smell of the lamp and are particularly cumbersome to use. Every other function one would care to use, and a few I hadn’t even thought about, seem to be controllable via a midi CC, apart from the ability to name and save a new preset, which is the function we are looking for.

Practically, this is a aspect of the functionality, that would easiest provided by the developers at Modartt. The user would be given the option of automatically generating a new preset file in their “My Presets” with the format

    <user determined preset name>_<current datestamp_current timestamp>.fxp

The desired configuration of Organteq could then be automatically saved and named by either pressing the designated keyboard shortcut, or by activating a predefined midi CC. Each time a preset is automatically saved it is assigned a unique filename, courtesy of the current datestamp and timestamp in the name. It would also be useful to have the ability to save these presets to a sub-folder of “My Presets”, so that presets associated with a particular project could be automatically assigned to their own project folder. This would allow preset combinations to saved “on the fly” whilst tweaking the organ for that special, perfect sound.

A user would still have the ability to save a new preset in the normal way, by typing “Ctrl + Shift + T” and by manually entering a unique name for the preset and then saving. The solution, suggested above, could be used to capture that fleeting “Oh, that sounds nice!” moment without having to think about it and pausing the creative flow.

If you are looking for “a programmer resource for Organteq to provide an accessible environment” then you might want to check out JUCE:

    https://juce.com/

which has the dual advantage of being free for personal use (assuming you are not making more than $50k per annum from your musical design work) and that Modartt use JUCE to construct both Pianoteq and Organteq, and it is always easier to work in the same programming environment. It has been a while since I’ve had to peak inside compiled binary programs and also look at linked libraries, but you can always come up with some interesting information, as, for example, the use of JUCE functions in the program. The utilisation of JUCE is also mentioned in

https://www.linuxjournal.com/content/pi...uct-review

and one reference in the Forum. I assume that this is commonly known, but I hadn’t come across it until I went poking around. However, I’ve usually found it easier to convince developers of the needfulness of a new tweak, if I can point to how their current programming environment already supports the required functionality.

The JUCE website has some tantalising projects in its tutorials, which may give you some ideas on how to approach the interfaces you want to construct. I am not a programmer, but the site has given me some thoughts on how to construct applications I want, even if I don’t particularly want to have to write the code for them. However, the programming interface seems to be a click and insert the relevant code or plugins, so even my woeful coding skills may not be an issue, though I am not holding my breath.

Something more to read and think on, I suppose, in our “free” time.

Michael

Interesting modules for the conversion of old organ consoles are offered by a Polish company..
https://www.midi-hardware.com/index.php...n=products

Thanks for the amazing link, just perfect for the job. well priced too.

I've thought about this for some time about producing organteq based consoles. I thought about this after asking a developer in the UK if he could help with designing / building what I'd need, sadly he let me down and with that any bond of trust was broken. So, thinking about it, providing there's a way of connecting switches without the need for solder (blind guy here so can't solder for toffee), then  I'd love to start building hand made organteq solutions with a little support, but for the moment, I need to concentrate on my own build first before I can decide on whether it's viable.

I don't suppose you could recommend any decent piston momentary switches and stop momentary switches? I'm having some headache trying to find a good supplier for not only bulk, but also decent quality that doesn't feel out of place for a console design.

Lew,

I will admit that the way I am utilising the "A/B" presets is NOT the method that is described in either the manual or the pop-up notes. However, I have spent years professionally getting software applications to jump through fiery hoops of my own devising, and this variation of the "A/B" preset functionality was to resolve part of the problem I was working on with the "en chamade" reeds.

I would see the redesigned  "A/B" presets function as being an interface into the Setter, where you could store the various configurations into memory. Each configuration could then be mapped to a particular piston on the physical console.

Organteq currently allows you to map a very large number of Combinations and combination banks, which I suppose are the equivalent of general piston stops. Divisional piston stops on the UI would simply be the remapping and duplication of this functionality under each of the divisional manuals. However, each combination ONLY allows you to trigger a pre-recorded state of stop drawknobs, coupler pedals and tremulant switches WITHIN a current organ. A combination DOES NOT allow you to change the FXP file currently loaded, nor does it allow you to retain changes to the Settings within a particular combination. However, an expansion of the "A/B" preset would allow for both of these options.

As the doors say in the Hitchhikers' Guide, "Glad to be of service!"

Michael

What if, just as a thought, what about an app for iOS as an example which could work as a programmer resource for organteq to provide an accessible environment for voicing, saving particular functions, etc, or if not an app, why not look at an example of compiling code for the various available controls, midi CC's available, etc and produce a control surface whic would allow say, per stop voicing, accessing particular parameters such as preset creation, etc.

one area which I'm not sure if it's available, is the ability to save a complete preset via midi CC, that said however it requires keyboard entry to create a file name, that could be bypassed and instead just create a generic data name per preset to navigate through sequence. there's midi assigns for preset up / down, etc so that's good, also midi assigns for the layers of general pistons.

yes, a good one regarding the doors.

lew

I will admit that the way I am utilising the "A/B" presets is NOT the method that is described in either the manual or the pop-up notes. However, I have spent years professionally getting software applications to jump through fiery hoops of my own devising, and this variation of the "A/B" preset functionality was to resolve part of the problem I was working on with the "en chamade" reeds.

I would see the redesigned  "A/B" presets function as being an interface into the Setter, where you could store the various configurations into memory. Each configuration could then be mapped to a particular piston on the physical console.

Organteq currently allows you to map a very large number of Combinations and combination banks, which I suppose are the equivalent of general piston stops. Divisional piston stops on the UI would simply be the remapping and duplication of this functionality under each of the divisional manuals. However, each combination ONLY allows you to trigger a pre-recorded state of stop drawknobs, coupler pedals and tremulant switches WITHIN a current organ. A combination DOES NOT allow you to change the FXP file currently loaded, nor does it allow you to retain changes to the Settings within a particular combination. However, an expansion of the "A/B" preset would allow for both of these options.

As the doors say in the Hitchhikers' Guide, "Glad to be of service!"

Michael

Lew,

A quick thought with respect to your point about the provision of general and divisional piston functionality within Organteq.

The "A/B" presets provide a rudimentary piston system for performances. A general configuration for the organ can be loaded on preset "A" and another configuration, be it either a general or divisional alteration of the stops, and Settings, can be loaded onto preset "B". One can swap from preset "A" to preset "B" by pressing the "C" on your keyboard. Organteq allows you the ability to reassign the "C" keyboard shortcut to another button on the console, via midi mapping. I assume that the "C" keyboard shortcut could be reassigned to a particular piston. However, I lack access to an organ console to test this assumption, but you may be able to test it.

As I said, this is a rudimentary system that allows you to store one general or divisional piston setting in memory, which is not particularly useful for a competent organist. However, if Organteq can allow you to store one piston in memory, then there is no reason why it can't allow you to store any number of general or divisional configurations in memory and then allow you midi map each one to a particular piston or keyboard shortcut. It is not as if Organteq is currently a memory hog, and loading a number of general or divisional configurations into memory would not unduly increase the level of memory usage.

If you want to increase the performance capability of Organteq by the introduction of general and divisional pistons, then I would suggest that this is most easily achieved by the expansion of the current "A/B" preset functionality to allow for more than two organ configurations to be loaded into memory, and also a note in the documentation on how to midi map the configurations to the required pistons. It would also be useful to have the ability to save the various registrations to a general piston configuration file for future reference.

If you want to expand the capabilities of a particular application is usually useful to suggest it via a minor modification of a currently operational function. From experience, I've found that this usually puts far less strain on the developers, rather than asking them to produce a brand new rabbit from scratch, which can be stressful for all concerned in the gestation

Michael

I was trying to work out what A/B was but VoiceOver couldn't give me translation because I'm having to map the software purely blind using 3rd party tools which don't always provide the details of functions. I like the idea of expanding on the A/B area though and you're right. Although from my perspective and that of anyone using Hauptwerk, divisional pistons below manuals to the UI would be the logical way to go.

Other than that, thank you so much for your amazing and valuable feedback and ideas.

lew

A quick thought with respect to your point about the provision of general and divisional piston functionality within Organteq.

The "A/B" presets provide a rudimentary piston system for performances. A general configuration for the organ can be loaded on preset "A" and another configuration, be it either a general or divisional alteration of the stops, and Settings, can be loaded onto preset "B". One can swap from preset "A" to preset "B" by pressing the "C" on your keyboard. Organteq allows you the ability to reassign the "C" keyboard shortcut to another button on the console, via midi mapping. I assume that the "C" keyboard shortcut could be reassigned to a particular piston. However, I lack access to an organ console to test this assumption, but you may be able to test it.

As I said, this is a rudimentary system that allows you to store one general or divisional piston setting in memory, which is not particularly useful for a competent organist. However, if Organteq can allow you to store one piston in memory, then there is no reason why it can't allow you to store any number of general or divisional configurations in memory and then allow you midi map each one to a particular piston or keyboard shortcut. It is not as if Organteq is currently a memory hog, and loading a number of general or divisional configurations into memory would not unduly increase the level of memory usage.

If you want to increase the performance capability of Organteq by the introduction of general and divisional pistons, then I would suggest that this is most easily achieved by the expansion of the current "A/B" preset functionality to allow for more than two organ configurations to be loaded into memory, and also a note in the documentation on how to midi map the configurations to the required pistons. It would also be useful to have the ability to save the various registrations to a general piston configuration file for future reference.

If you want to expand the capabilities of a particular application is usually useful to suggest it via a minor modification of a currently operational function. From experience, I've found that this usually puts far less strain on the developers, rather than asking them to produce a brand new rabbit from scratch, which can be stressful for all concerned in the gestation

Michael