Separate audio API into a nannou_audio crate
#331
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The motivation behind this is to avoid flooding nannou itself with APIs for every kind of creative I/O we eventually implement. Nannou's build times are already very unwieldy and I think this could easily get out of hand if we continue to add everything into the one crate. This change slightly improves build times for users who don't need or care about audio. In a similar manner, the laser API also exists in its own crate called [lasy](https://github.com/nannou-org/lasy). Maybe the name should be changed from `lasy` to `nannou_laser`, and we can make this a consistent theme for supporting different higher-level creative I/O stream APIs (e.g. `nannou_dmx`, `nannou_midi`, etc)? The `simple_audio.rs` example has been updated to demonstrate use of the new `nannou_audio` crate. cc @freesig @JoshuaBatty what are your thoughts on this? I've been meaning to get around to this for a while. My original concern was that we might not be able to keep an "as-simple" API if we were to move everything into its own crate, but I'm pretty happy with how the example's looking in this case. Pretty much everything is identical except the audio API has been removed from the `app.audio` field to its own type in its own crate.
mitchmindtree
force-pushed
the
separate_audio
branch
from
6d9c6db to
078b144
Compare
|
Yeh I think this is a good idea. |
|
Nice the updated example still looks super simple enough. I'm also a fan of going with the |
|
Sweeeeet! Maybe as this is a pretty hefty breaking change I'll leave this up for a bit until we've announced 0.9 and done some more non-breaking stuff on 0.9 first. |
mitchmindtree
added a commit
to mitchmindtree/nannou
that referenced
this pull request
Jun 8, 2019
See nannou-org#331 for the motivation behind this. The `osc_sender` and `osc_receiver` examples have been updated to use the new `nannou_osc` crate, with only one line change necessary for both examples. Like nannou-org#331, it's probably best to wait until we're ready for a 0.10 release before merging this as it's a breaking change.
mitchmindtree
added a commit
to mitchmindtree/nannou
that referenced
this pull request
Jun 13, 2019
This does not address the audio or osc modules as they will be moved into independent crates as of nannou-org#331 and nannou-org#334.
|
OK the 0.9 ship sailed successfully and there's a growing desire for quite a few changes that will involve some breakage on the horizon (palette crate update, addition of a loop mode, etc) so I think it's safe to start merging these in prep for a 0.10! |
mitchmindtree
added a commit
to mitchmindtree/nannou
that referenced
this pull request
Jun 19, 2019
See nannou-org#331 for the motivation behind this. The `osc_sender` and `osc_receiver` examples have been updated to use the new `nannou_osc` crate, with only one line change necessary for both examples. Like nannou-org#331, it's probably best to wait until we're ready for a 0.10 release before merging this as it's a breaking change.
mitchmindtree
added a commit
to mitchmindtree/nannou
that referenced
this pull request
Jun 19, 2019
See nannou-org#331 for the motivation behind this. The `osc_sender` and `osc_receiver` examples have been updated to use the new `nannou_osc` crate, with only one line change necessary for both examples. Like nannou-org#331, it's probably best to wait until we're ready for a 0.10 release before merging this as it's a breaking change.
mitchmindtree
added a commit
to mitchmindtree/nannou
that referenced
this pull request
Jul 21, 2019
Time for v0.10! Here are some of the main changes to look out for: **Colour Overhaul** nannou-org#355 The **palette** crate dependency has been updated from v0.2 to v0.4. Nannou's old named colours (e.g. DARK_BLUE, PURPLE, etc based on the Tango desktop color selection) have been removed in favour of using the named colours provided by palette which are much more extensive and based on the the CSS spec. This means there's a high chance some of your code or colors might break! In some cases certain colours will be missing, in other cases the colour may now look different. We've added a new `named_color_reference.rs` example that should hopefully make it a little easier to find equivalent colours from the new selection. Friendlier colour constructors have been added to the prelude, so e.g. now we can do `rgb(r, g, b)` rather than `Rgb::new(r, g, b)`. The same goes for `hsl`, `hsv`, etc. The color constructors that take a continuous hue value as an argument (e.g. `hsl`, `hsv`) have been simplified so that they now expect the hue as a normalised value between 0.0 and 1.0. **View API Tweak** nannou-org#368 The `view` function used for presenting graphics to the frame for a window has been changed slightly so that the `Frame` argument is taken by reference, rather than by value. See nannou-org#366 for the motivation behind this change. This should hopefully be an easy fix - check out any of the updated examples to see how to update your view function signature. **Audio and OSC Refactor** nannou-org#331 nannou-org#334 The `osc` and `audio` modules have been moved into their own `nannou_osc` and `nannou_audio` crates respectively. This should hopefully speed up compile times a little for users who are using nannou purely for graphics/sketches and don't require either. There is very little difference in terms of usage and if you are using either the `osc` or `audio` modules breakage should be minimal - you can check out the osc or audio examples and the linked PRs for a demonstration of how to update your code. **NTimes Loop Mode** nannou-org#353 A new loop mode has been added that allows for looping *n* number of times before stopping and presenting only the last frame. This should be useful for users who only wish to render a single frame, or perhaps a specific number of frames for a fixed length animation. --- For more information on the other changes included within this release checkout the CHANGELOG!
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The motivation behind this is to avoid flooding nannou itself with APIs
for every kind of creative I/O we eventually implement. Nannou's build
times are already very unwieldy and I think this could easily get
out of hand if we continue to add everything into the one crate. This
change slightly improves build times for users who don't need or care
about audio.
In a similar manner, the laser API also exists in its own crate called
lasy. Maybe the name should be
changed from
lasytonannou_laser, and we can make this a consistenttheme for supporting different higher-level creative I/O stream APIs
(e.g.
nannou_dmx,nannou_midi, etc)?The
simple_audio.rsexample has been updated to demonstrate use of thenew
nannou_audiocrate.cc @freesig @JoshuaBatty what are your thoughts on this? I've been
meaning to get around to this for a while. My original concern was that
we might not be able to keep an "as-simple" API if we were to move
everything into its own crate, but I'm pretty happy with how the
example's looking in this case. Pretty much everything is identical
except the audio API has been removed from the
app.audiofield to itsown type in its own crate.