And disabled by default, at that. I can't actually hear the difference
of Peak Extension in the Rock track I have that claims to use it. And
Low Level Range Extension is more trouble than it's worth on tracks that
use it by mistake, or maliciously, if the case may be. I may add track
tag level control in the future.
Signed-off-by: Christopher Snowhill <kode54@gmail.com>
Also hide the Apple plugins from settings so they don't get activated
unless there's no SoundFont configured.
Signed-off-by: Christopher Snowhill <kode54@gmail.com>
If the current track has played for more than 5 seconds, previous track
now restarts the current track, instead of jumping back to the previous
track.
Signed-off-by: Christopher Snowhill <kode54@gmail.com>
Clearly, NSUserDefaults bindings were not really meant to be used in
practice at all, as they do nothing but crash the app.
Signed-off-by: Christopher Snowhill <kode54@gmail.com>
Change hotkey storage system, hopefully this will fix the stability
issues that have been plaguing it for a while now.
Signed-off-by: Christopher Snowhill <kode54@gmail.com>
It turns out that initializing NSUserDefaultsController like this is a
really bad idea, especially on older versions of macOS. This is probably
also why the equalizer was crashing for people on first activation.
Signed-off-by: Christopher Snowhill <kode54@gmail.com>
Pitch and tempo weren't snapping to exactly 1.0 before, as a result of
various things. This fixes that.
Signed-off-by: Christopher Snowhill <kode54@gmail.com>
Option to make selection follow the playback, within the lag of the
output buffer, including if Always Stop After Current or Repeat One is
enabled. Allows easily queueing up a list of tracks in Always Stop mode,
then hitting the Play button again to play the next track. Enabled by
default, but always optional to disable.
Signed-off-by: Christopher Snowhill <kode54@gmail.com>
A new menu option under the Control menu, disabled by default, which
stops playback after the current track completes.
Signed-off-by: Christopher Snowhill <kode54@gmail.com>
Add event traces to playlist loading and metadata processing queues.
Unfortunately, most of the old non-error events should not be logged,
because Sentry gets terribly spammy with captureMessage events. They
should only be used for error events, or other uncommon events which
do not already throw exceptions or NSError objects.
Signed-off-by: Christopher Snowhill <kode54@gmail.com>
Enable processor usage profiling for the app to gather information for
potential bottleneck tracking.
Signed-off-by: Christopher Snowhill <kode54@gmail.com>
Cleaned up project settings to current defaults, except for the macOS
deployment version, which is still 10.13. Cleaned up a lot of headers
and such to include with angle braces instead of double quotes. Enabled
build sandbox in a lot of places. Disabled subproject signing in several
places, for libraries and frameworks which will be stripped and signed
when they are copied into place in the final build.
Also, while trying to solve compilation issues, the visualization
controller was reverted to the Objective C implementation, which is
probably faster anyway. Stupid Swift/Objective-C language mixing issues.
Signed-off-by: Christopher Snowhill <kode54@gmail.com>
This includes setting and unsetting the equalizer DSP chain objects on
track change and advancing on track playback end, and also bugs with
applying equalizer presets to the band configuration items when the
equalizer is disabled or when playback is stopped.
Fixes#420
Signed-off-by: Christopher Snowhill <kode54@gmail.com>
This should not interact with the Audio Player object on a background
thread, but instead the main thread queue.
Signed-off-by: Christopher Snowhill <kode54@gmail.com>
Two playback event items were set to queue a playback start to a
background thread, when playback should instead be queued on the main
thread. Fix this in a simple way.
This crash was easily reproducible by skipping through tracks rapidly.
Signed-off-by: Christopher Snowhill <kode54@gmail.com>
And disable it by default in new installations, otherwise leave the
setting alone. The disablement setting is shared with the engine
setting, so the default should not really change anything, except for
new installs.
Also, the time/pitch shifting dialog disables itself and displays an
obvious notice button, which opens the Rubber Band settings.
Signed-off-by: Christopher Snowhill <kode54@gmail.com>
These should have been defined already, but now they're the safe
defaults that should spring the dialog on startup, and doesn't grant
consent by default.
Signed-off-by: Christopher Snowhill <kode54@gmail.com>
In case multiple playlist entries are left marked as "current" in the
playlist database, resume playback on the first one, and unmark all the
rest of them.
Signed-off-by: Christopher Snowhill <kode54@gmail.com>
This class can more flexibly process and emit varying chunk sizes than
the previous code could, solving the problem of wide tempo changes.
Signed-off-by: Christopher Snowhill <kode54@gmail.com>
It should also be possible to sort by the column, ascending or
descending. This also necessitated adding playlist row refreshing
for play count updates.
Signed-off-by: Christopher Snowhill <kode54@gmail.com>
The NSCalendar assignment should have a placeholder month and day
of January 1st, instead of the invalid month/day of 0/0. Also,
even if this somehow fails, don't attempt to assign it if it
returns nil.
Signed-off-by: Christopher Snowhill <kode54@gmail.com>
I will implement the more complex setup of providing options for
most of the configuration that Rubber Band provides, at a later
date, when I feel like creating a complex configuration dialog
for it, and asking for help translating every option and setting.
Signed-off-by: Christopher Snowhill <kode54@gmail.com>
The emoji labeled buttons will convert and save their respective
state icon to the settings folder, and refresh the current icon
as necessary.
Signed-off-by: Christopher Snowhill <kode54@gmail.com>
Implements a simple speed control using a resampler
designed for real time changes. A rubberband speed
control will be implemented at a later date.
Signed-off-by: Christopher Snowhill <kode54@gmail.com>
Perform playback start and seeking operations in the background, instead
of on the main thread, which should help prevent them from stalling the
user interface.
Signed-off-by: Christopher Snowhill <kode54@gmail.com>
Instead of clear playlist and play. This was confusing people,
apparently. I should have changed it sooner, since this is what
I use normally anyway.
Signed-off-by: Christopher Snowhill <kode54@gmail.com>
Defaulting to ctrl-cmd-O, though I may change this if
someone has any better ideas for a default.
Signed-off-by: Christopher Snowhill <kode54@gmail.com>
AppleScript is apparently such a legacy system, that when it sends URLs
to your app to open, they're in the old Carbon format. So we need to
translate these to proper URL strings for the rest of the app to deal
with them at all.
The format of these URLs is as follows:
/method/::
Followed optionally by:
username/password@
Where the slash and password are optional.
Followed by:
hostname
Followed optionally by:
/portnumber
And finally, followed by:
:path:on:server:filename.ext
So, in hostname field, we must swap slashes to colons. And in the path
field, swap colons to slashes. What a bizarre world.
Signed-off-by: Christopher Snowhill <kode54@gmail.com>
This change had several components. For one, the delay of the dispatch
was increased from 5 milliseconds to 50 milliseconds. Two, the post to
the notification center was included in the delayed dispatch, so that
retains the PlaylistEntry object. Finally, the playlistController's
currentEntry object is reassigned from the input PlaylistEntry object,
which facilitates all watchers which are observing that variable for
updates. This final step also retains self for the callback, which
should be fine, since it's a quick dispatch with a short delay.
Fixes#335
Signed-off-by: Christopher Snowhill <kode54@gmail.com>
This should not really be necessary for proper player operation any
longer, and can safely be removed.
Signed-off-by: Christopher Snowhill <kode54@gmail.com>
All concurrency from other threads should pass through the viewContext's
performBlock or performBlockAndWait functions, and no other way. So now,
all access to Core Data is either happening on the main thread, or by
using these code blocks, all of which will wait for their access to
proceed.
Signed-off-by: Christopher Snowhill <kode54@gmail.com>
This should fix up potential locking issues with maintaining a copy of
the results set while certain other background actions may happen, such
as the player updating play counts while playing.
Signed-off-by: Christopher Snowhill <kode54@gmail.com>
