Forums

Hello everybody at MCdx -

while trying out your already very nice piece of software, I nevertheless ran into some strange behaviour, mostly when dealing with loops:

- To begin with, setting loop mode and adjusting the in/out-markers will not always create a new loop entry in the left panel unless I drag the audio item into the loop section.

- With many loops, the on/off state for the inspector's Adjust and FxChain tabs is not saved correctly. Changes to whichever state has been saved in the first place will not be remembered across sessions. Global is off in the pref pane.

- With some loops, the built in EQ is active although the box is not checked and the sliders are greyed out. To switch the EQ off, I have to check, then uncheck the box. In the next session, the behaviour will be identical.

- Changing the play position by clicking within a running loop plays the loop to the end marker, then starts playback of the next item in the list. At the same time, a new line appears in the loop list, which is a copy of an existing one - usually either the last one played or the current one. Now *this* is confusing.

- Whenever the program starts, it asks whether it should accept incoming network traffic. Whichever way I decide, it will keep asking every time around. I tried changing things in the System Preferences, but nothing helps. What is it doing, anyway?

- The inspector and other HUD panels (that the word?) are just a bit too transparent for my taste. Things can get rather detailed and complicated in them, and then still seeing the various lists and stuff of the main window coming through to a degree where I can read it seems rather unergonomical to me. I really have to concentrate on what I want to see and what not.

Keep up the Good Work & best wishes - Niko

Hi Niko,

Dragging markers and setting Loop mode after a track has started playing doesn't automatically create a Loops entry... but re-cue-ing the loop or double-clicking it in the list view should add the entry when in Loops mode. Once loop mode is enabled, any new tracks that aren't sourced from an AudioCodex playlist that are started will get an entry automatically added in the Loops playlist.

I don't do automatic loop-duplication if Loop mode is turned on while playing so that flicking loop mode on and off accidentally doesn't trigger a duplication of the track un-necessarily, and as you discovered, there are some other ways to unintentionally duplicate a loop.

The duplication of loops on next previous clicks in loop mode is a bug we can confirm, and was something we missed, thanks for pointing it out, this will be fixed in the next update which is due out some time in the next few days.

Re settings not being restored properly, we have been repairing some inconsistencies over the past two releases. Getting the logic right for what to do when either no settings exist ( ie first-play of a track), or when global mode is enabled has been trickier than I expected.

In our initial implementation, in CoreAudio mode, if no settings existed for eq or reverb for a track, they would be regarded as pseudo-globals, and their settings from the previous track would be maintained, as was volume & pan. Time & Pitch warping were dealt with oppositely, in that they are assumed to be 'off' unless the user has settings other that Time = 1. & Pitch = 0, in which case they would be applied, and Warp would be turned on, with no regard to it's enabled state at the time the track last ended. My basic idea was that Reverb and Eq would usually / always be 'on', as each consumes relatively little CPU time, while Warp should only be turned on if non-null values applied to it, due to the large increase in CPU utilisation that enabling Warp entails. My code focussed on gathering those settings correctly as tracks were played, and didn't turn Reverb or Eq off when replaying, just applied new settings if the tracks stored settings were different.

There were even more inconsistencies in how settings were saved and applied for QuickTime-mode playback; AudioCodex was conceived primarily as CoreAudio player, but when QuickTime 7.0 added the ability to control pitch and rate independently ( for files with an audio track ) it seemed prudish to exclude it completely, so we added some basic support for QuickTime files. AudoCodex's handling of QuickTime mode has long been a poor cousin to CoreAudio mode in terms of saving and restoring settings per-track properly, but for the next release, I have I think finally bought QuickTime mode into the 21st century wrt obeying Global mode, and respecting volume, pan, bass , treble, rate & pitch settings appropriately for both first-play and re-play situations.

After 1.0 was released I started on the first stage of tightening-up the rules for effects settings for first-play and re-play, and added some preferences to allow the user to specify the behaviour for first-played tracks in 1.1; unfortunately this initial implementation didn't go far enough wrt fully respecting the enabled / disabled state of effects. This functionality should finally be working properly in the next release; all aspects of effects including the enabled state, global state and first-play preferences should be consistently respected and restored.

Re Network access alerts, it is most likely that the Preferences option to 'Check for software updates at launch' is ticked. If this is enabled, each time the app is launched it attempts to download a single XML file (RSS feed) from our server, to determine if a new update to AudioCodex is available. Feel free to turn this Preference off as you will, it is only provided as a convenience, and updates can be manually checked at any time using the 'Check for updates...' item in the AudioCodex menu, or by subscribing to the Forum RSS feed, as we announce all updates in the Forum. For those that are interested, we use the open-source Sparkle library to implement this functionality, as do many other independent Mac developers.

Re the HUD transparency, we are using values that are close to / the same as those used by Apple in Leopard HUD's, but as ours are custom windows we may be able to provide some relief via a preference setting in a future release ( but probably not the very next release...).

Thanks again for the reports & observations, look for some more improvements and bugfixes in the next release.

Cheers,

Mark

Hi Mark,

thank you for your very quick response and in-depth explanations. Yes, I can understand how a seemingly simple, foolproof concept comes up with an increasing number of snags and snaglets the closer you come to actually implement or utilize it. Looking forward to the next release - I'll most certainly have a thorough look at it. (Probably going on vacation before, though.)

Cheers,

Niko