Zynewave@Guaranath wrote:
Greetings all!
Greetings.
I recently got an app for my iPad that is called TouchOSC, it is designed to be a MIDI controller for your desktop DAW (and obviously an OSC controller as well). You can edit and design your own templates to suit your needs or your DAW, so I was curious if anyone uses this app and has already designed a template for Podium? If not, I have read here that Podium uses the Mackie standard control setup – so theoretically I could design my own template assigning the Mackie standard designations?
That should be possible. I have no experience with the TouchOSC app, but I think it’s likely that some user already has created an MCU emulation. Perhaps these can be downloaded somehow.
Zynewave@druid wrote:
If you don’t mind me asking, Frits, was the reason you compressed the project files in the first place? Was it related to space utilisation, or were there other considerations?
Space/speed considerations. The .pod format was conceived many years ago, when this truly was an issue. For the updated project file format, I’m considering using http://www.sqlite.org . I have already made some experiments with it, but I haven’t yet determined if it will be efficient enough for real-time project storage.
ZynewaveMake sure you haven’t selected the Axiom input on the “control surfaces” page in the interfaces dialog.
ZynewaveHi,
The Podium mixer can only be controlled by Mackie Control Universal (MCU) compatible devices. I did a quick search on Pro 88, and it doesn’t seem like it can emulate MCU mode.
Frits
ZynewaveZynewave@The Telenator wrote:
Finally for now, all users should be aware that the latest word I think we’ve heard from Frits is that the Microsoft Windows 8 tablet PC Podium-compatible build is going to happen. This, as I’m sure you all know, is a real chunk of time and work for Podium to function properly in a teeny weeny place (storage, memory, processing, etc.) It will influence other feature designs for a while. Right?
Right. I can’t do much more to optimize memory and processing, but there are some challenges with storage. Portable devices (including Win8 tablets) requires that apps can terminate within a few seconds, in case the device needs the memory for another app or if it needs to shut down due to low power. Any unsaved changes must be stored to disk within 1-2 seconds or else the data is lost. Thus, it is not possible to have a complete unsaved project with audio residing just in memory. Project changes need to be committed to file continuously in the background without disturbing the user. To be able to do this I’m considering updating the Podium project file format, as the current file format is compressed and not designed to be partially updated. One side-bonus of this revision, is that it serves as auto-backup in case of crashes. Auto-backup is another major feature that I’m surprised to see no one has mentioned yet in this topic.
ZynewaveI searched for 4-way mouse wheel scrolling, and found a couple of new Microsoft mice (MS Touch Mouse and MS Explorer Touch Mouse), which support speed-adjustable horizontal scrolling. I think the Logitech touch mouse supports 4-way scrolling as well. I’ve now spent a couple of hours adding the support for WM_MOUSEHWHEEL, for the upcoming 3.1.1 release.
Zynewave@druid wrote:
Ah, I would’ve never made presets in plugins with unicode characters because of the fear that it would result in question marks!
It shouldn’t be harmful though, if the question marks appear.
Other than presets, are you aware of any textual data that would transmit between VST and host, that the user can edit, that might contain unicode? Are folder paths transmitted between Podium and VSTs? Naturally if the VST itself loads, it’s entirely within the VST itself, but I was wondering if some VSTs request paths from the host.
Can’t think of any.
Zynewave@Poobah wrote:
@Zynewave wrote:
I remember testing this a couple of years ago, and was not happy with the result. I have a mouse with side-tilt, but it provides horrible accuracy.
Wouldn’t it be better to have it available for the users who would use it? The users who don’t like it could just not use it. I don’t think its accuracy is any worse than a scroll wheel; they both scroll a fixed amount that is configurable in Windows.
Is the code for the tilt support the same as for a horizontal scroll wheel? (I mean checking for a WM_MOUSEHWHEEL window message.) I remember once having a mouse that had two scroll wheels – one for vertical and one for horizontal. It’s useful when applications support both directions rather than ignoring the horizontal scroll messages.
My mouse only supports on/off side tilt of the wheel, which means you cannot adjust the speed of scroll as you can by rotating the mouse wheel. The WM_MOUSEWHEEL message only reports vertical scroll wheel. Considering the time required to implement this feature, and the small number of users who will find it useful, I put this feature request at a very low priority.
The reason I’m talking about all of this scrolling stuff is I find this aspect of the program a bit annoying. With most good Windows applications, you can scroll using a native scroll bar, horizontal scroll wheel or using the middle mouse button. With Podium, you can’t do any of these. I know that you can use the viewport thing at the top of the arrangement editor to scroll horizontally, but it also scrolls vertically, which I find annoying; I don’t want the arrangement to be scrolling around vertically when I’m trying to scroll horizontally.
If you want horizontal scrollbars in the editors, it is possible to add those by editing the editor profiles (adding a scrollbar region). Editing the profiles requires some insight into how the profiles work though, as it’s possible to mess up the editors. If that happens, use the “restore default editor profiles” setup menu command.
The reason the horizontal scrollbars are not there by default, is because they take up space, and that there are plenty of other ways to navigate. Personally I found that I never used the scrollbars. I always use the Ctrl+Alt+Shift key combinations to activate the zoom/slide tools, or hover the mouse over the “Navigator” at the top and use the mouse buttons/wheel. If you click above/below the marked range in the navigator, you can scroll horizontally with vertical position locked.
ZynewaveSynthMaker still does not support generating 64-bit VSTs, which I feel is a requirement to be able to supply Nucleum as part of the Zynewave plugins bundled with Podium x86/x64. Until SM supports 64-bit VST export, I won’t spend time improving Nucleum.
Zynewave@pbattersby wrote:
Try the following.
– Solo a couple of tracks
– Bounce using the master track (off-line render bounce)
– Try to Unbounce the master trackUntil I first unsolo everything, I can’t unbounce. I’m using version 2.40.
Thanks. This is now fixed in 3.1.1.
ZynewaveThanks. Fixed in 3.1.1.
ZynewaveOld topic, I know, but as I was going through my list of unresolved topics, I noticed this one may have been fixed with the latest 3.1.1 beta release.
Zynewave@Poobah wrote:
(However, couldn’t Podium just always put imported MIDI tracks inside a single audio-capable master track so that it works automatically and is structured like normal arrangements?)
It could, and I may change this some day. Some users may work exclusively with MIDI, and so would not need the master audio track.
I think it would also be good if Podium supported horizontal mouse-wheel scrolling. Some mice support tilting the scroll wheel left and right to scroll horizontally. Standard windows controls seem to support this. Could Podium also support this so that such users can easily scroll horizontally in the arrangement editor?
I remember testing this a couple of years ago, and was not happy with the result. I have a mouse with side-tilt, but it provides horrible accuracy.
Zynewave@druid wrote:
32-bit seems to work with unicode, I tried loading and saving unicode filenames, and renaming items within Podium with Japanese.
Are there any areas that are still dependant on ASCII or similar, or has everything been uypgraded to unicode? Do notes, device names etc. all support unicode now?
All text handling within Podium is now Unicode. Windows stores Unicode strings as double-byte (16-bit) characters. Whenever Podium needs to save/load strings in files and VST/ReWire plugins, the strings are converted to the single-byte (8-bit) UTF-8 format. A UTF-8 string that does not contain Unicode specific characters is identical to the ASCII version of the string. The UTF-8 conversion is necessary since the VST and ReWire communication interfaces only support strings with single-byte characters.
Using UTF-8 should ensure compatibility with plugins that do not support Unicode. If a plugin supports UTF-8 conversion, then it should be possible to name e.g. VST presets in Podium with Unicode characters, and have them appear correctly in the plugin UI.