profile
viewpoint

glium/glium 2104

Safe OpenGL wrapper for the Rust language.

freesig/shade_runner 6

A shader hotloader for vulkano.

mitchmindtree/CppGen 2

Generate one or more .cpp and .h file pairs from your own template with a single command.

mitchmindtree/coinnect 1

Coinnect is a Rust library aiming to provide a complete access to main crypto currencies exchanges via REST API.

mitchmindtree/conrod_graph_widget 1

A general use widget for viewing and controlling graphs.

mitchmindtree/cpal 1

Low-level library for audio input and output in pure Rust.

freesig/socket_finder 0

Smart socket finding for Rust

MindBuffer/cohen_gig 0

Wash lighting and LED visualisation and DMX control for the upcoming Josh Cohen gig.

mitchmindtree/alsa-rs 0

Thin but safe ALSA wrappers for Rust

mitchmindtree/ann 0

An Artificial Neural Network library written in Rust.

issue commentnannou-org/nannou

Simple window example crashes when pressing mouse button 4 (or 5)

Ahh thanks for the issue! It looks like this is the same issue as #337.

MarkuBu

comment created time in 12 hours

startedidris-lang/Idris2

started time in a day

PR opened nannou-org/nannou

`nannou_ui` crate WIP gui

Currently a very, very early WIP of #383 and #430 It may not compile, and is likely to change often as I continue to experiment and try out different things. I thought I'd open a PR so it's easier for folks to keep track of progress and make suggestions. I'll update this comment once I have something a little more solid.

+1108 -0

0 comment

12 changed files

pr created time in a day

create barnchmitchmindtree/nannou

branch : nannou_ui

created branch time in a day

delete branch mitchmindtree/sample

delete branch : dasp

delete time in a day

delete branch mitchmindtree/sample

delete branch : publish_delay

delete time in a day

push eventRustAudio/dasp

mitchmindtree

commit sha d46b8fa4006e363e03a5a7d8847c589d54990c57

Add a 5 sec delay between publishing each crate It seems that we need to introduce a bit of a delay to let crates.io properly register each package before before publishing its descendents. Otherwise, they compile so fast that crates.io returns an error saying that the dependencies don't exist.

view details

mitchmindtree

commit sha 16f7498dcaae4201219bd6fecad94724686de2e6

Merge pull request #125 from mitchmindtree/publish_delay Add a 5 sec delay between publishing each crate

view details

push time in a day

PR merged RustAudio/dasp

Add a 5 sec delay between publishing each crate

It seems that we need to introduce a bit of a delay to let crates.io properly register each package before before publishing its descendents. Otherwise, they compile so fast that crates.io returns an error saying that the dependencies don't exist.

+20 -0

0 comment

1 changed file

mitchmindtree

pr closed time in a day

PR opened RustAudio/dasp

Add a 5 sec delay between publishing each crate

It seems that we need to introduce a bit of a delay to let crates.io properly register each package before before publishing its descendents. Otherwise, they compile so fast that crates.io returns an error saying that the dependencies don't exist.

+20 -0

0 comment

1 changed file

pr created time in a day

create barnchmitchmindtree/sample

branch : publish_delay

created branch time in a day

issue openedRustAudio/dasp

What happened to `sample`?

Recently the sample crate was renamed to dasp as a part of an overhaul aimed at improving the crate's modularity. See #120 for further rational.

Also be sure to visit v0.11 at the CHANGELOG for more details on precisely what has changed.

created time in a day

push eventRustAudio/sample

Pieter Penninckx

commit sha 866343459bc5eed9568b7fdaab0fa225d4f9a2ec

Use cargo features.

view details

Pieter Penninckx

commit sha 76be6614d760683e38fe240c7217e561c226e32d

Update .travis.yml

view details

Pieter Penninckx

commit sha aa274b65ac0e32ecf0ecb25c83384b6b82066c7b

Move impl blocks to lower the number of cfg's.

view details

Pieter Penninckx

commit sha 8412880319e188fd065fd08ca9cc3f92f85e2bbc

rustfmt frame.rs

view details

mitchmindtree

commit sha e6cf78cdbe8c46814e7f6da2c11071b4f5d9e2e5

Rename `sample` to `dasp`. Split features into multiple crates. This PR is based on @PieterPenninckx's great work in #116 and some of the past discussion that has occurred around improving the modularity of the`sample` crate. Having the crate split into features as in #116 made it easier for me to identify how to untangle the various modules into independent crates. **sample** -> **dasp** The direction of splitting up the crate into multiple sub crates has been on my mind for a long time, though the name `sample` always seemed unsuitable to as an umbrella term for the sub-crates of the project. After spending a bit of time throwing around different acronyms and abbreviations, @JoshuaBatty suggested **dasp** for digital audio signal processing. I think it rolls off the tongue pretty well! **Repo structure** The repository is now structured as a workspace consisting of a suite of subcrates. The **dasp** crate is the top-level crate, re-exporting each of the sub-crates and providing features that map not only to each of the sub-crates, but also to each of the sub-crate features too. **TODO** I thought I'd post this PR now to allow for feedback and thoughts. That said, there are still a few things I'd like to address before landing this: - [ ] Remove travis-ci in favour of github workflow CI with auto-publishing and a nice way of testing feature set permutations and with/without std. - [ ] Port synth.rs and play_wav.rs examples from portaudio to cpal. - [ ] Add CHANGELOG wich section on migrating from `sample` -> `dasp`. - [ ] Complete the "crates" table within the top-level README. - [ ] Add a graphviz png of the dasp dependency tree to the README. - [ ] Add a note to the docs of feature-gated items specifying required features. - [ ] Publish a new version of `sample` with a README notice about switching to `dasp`. There are many other items I'd like to address, but they are likely best left for future PRs. cc @PieterPenninckx, @andrewcsmith Closes #116. Closes #112.

view details

mitchmindtree

commit sha f948eca0d58f53e9ce7ed712388fecee2721a7c6

Remove portaudio from examples in favour of cpal

view details

mitchmindtree

commit sha bd200767758661d77864ce89b4731c40e986b223

Add `all-features-no-std` features. Remove travis in favour of workflow Also adds auto-publishing when pushing to master and more thorough testing of different combinations of features and no_std.

view details

mitchmindtree

commit sha f35a13453a893a28033cae3a0576faeac30257ea

Add dependency graph image to assets directory

view details

mitchmindtree

commit sha 5e0a1df2c8cfdb35faf4e7a79af843c530de1a8f

Update top-level README with info on included crates and no_std

view details

mitchmindtree

commit sha 4252cfa3730e6cd6f6ac601cdc14654c2f426444

Run cargo fmt on whole repository

view details

mitchmindtree

commit sha bb73ff66069add3aaf0f0c0e3c981408c02f73ad

Use nightly for no_std CI builds. Fix no-default-features tests.

view details

mitchmindtree

commit sha d5b5f2376f9ff7a25e1a95387f4a64e0153fc52d

Remove resampled wav from repo. Add to gitignore.

view details

mitchmindtree

commit sha 6090e7f9f14721a1553da73899e1efae6b3acd88

Formatting and link fixes for README

view details

mitchmindtree

commit sha 5f38099f07ca4709e60057665ad1f598870aa462

Add action status badge to top of top-level README

view details

mitchmindtree

commit sha 32776adda61c9a9241f0ddef9b69656a0fbb7deb

Remove remaining readme content from dasp_sample to top-level

view details

mitchmindtree

commit sha 895d25fdfb48787f1b9979119432aedcf0c19743

Fix dasp_frame mul_amp example

view details

mitchmindtree

commit sha 27590daf71bd95fc447deec9694ea6f11648af1b

Prepare crates for publishing under version 0.11.0. Rather than starting from version 0.1.0, I thought it would make sense for versioning to continue on from where the `sample` crate left off.

view details

mitchmindtree

commit sha 8a62a9844b66e3ce8456153929a052e304bf5aca

Complete missing entries from new dasp cargo manifests

view details

mitchmindtree

commit sha e2d1b15f4a1cc43fe2d0258642dbcf382353aad8

Add missing no_std attr to dasp

view details

mitchmindtree

commit sha 06d8822b94870de3943c85e29dccf037f25dac70

Enable all features for dasp_ring_buffer docs.rs metadata

view details

push time in a day

PR merged RustAudio/sample

Rename `sample` to `dasp`. Split features into multiple crates.

This PR is based on @PieterPenninckx's great work in #116 and some of the past discussion that has occurred around improving the modularity of thesample crate. Having the crate split into features as in #116 made it easier for me to identify how to untangle the various modules into independent crates.

sample -> dasp

The direction of splitting up the crate into multiple sub crates has been on my mind for a long time, though the name sample always seemed unsuitable to as an umbrella term for the sub-crates of the project. After spending a bit of time throwing around different acronyms and abbreviations, @JoshuaBatty suggested dasp for digital audio signal processing. I think it rolls off the tongue pretty well!

Repo structure

The repository is now structured as a workspace consisting of a suite of subcrates. The dasp crate is the top-level crate, re-exporting each of the sub-crates and providing features that map not only to each of the sub-crates, but also to each of the sub-crate features too.

TODO

I thought I'd post this PR now to allow for feedback and thoughts. That said, there are still a few things I'd like to address before landing this:

  • [x] Remove travis-ci in favour of github workflow CI with auto-publishing and a nice way of testing feature set permutations and with/without std.
  • [x] Port synth.rs and play_wav.rs examples from portaudio to cpal.
  • [x] Complete the "crates" table within the top-level README.
  • [x] Add a graphviz png of the dasp dependency tree to the README.
  • [x] Add CHANGELOG with section on migrating from sample -> dasp.
  • [x] Add a note to the docs of feature-gated items specifying required features. Try this.
  • [ ] Publish a new version of sample with a README notice about switching to dasp.

There are many other items I'd like to address, but they are likely best left for future PRs.

cc @PieterPenninckx, @andrewcsmith

Closes #116. Closes #112.

Edit: For those migrating from sample, be sure to visit the new CHANGELOG and see the top-level documentation for the new dasp crate.

+4709 -3587

0 comment

73 changed files

mitchmindtree

pr closed time in a day

PR closed RustAudio/sample

WIP: Use cargo features.

Closes #112 , at least once it's finished.

This is a WIP (work in progress) for now.

It works, but I'm not sure how to proceed for the following reasons:

  1. Quoting the cargo docs:

In almost all cases, it is an antipattern to use these features outside of high-level packages that are designed for curation. If a feature is optional, it can almost certainly be expressed as a separate package.

  1. (continued) Now I don't think (correct me if I'm wrong) that sample is a high level package designed for curation like piston since it does more than just re-exporting things from other crates (piston does nothing more than re-exporting stuff from other crates). So if we take this advice at heart, then I think sample should ideally be split up into separate crates. In my opinion, using cargo features can be a good transitional step in that direction, so this doesn't immediately render this pull request useless, but it raises a question that makes me think.

  2. There are a lot of inter-dependencies between the different features in the Cargo.toml file. I don't know if these inter-dependencies make sense. For the conv module, I tried to remove all dependencies on features, but that resulted in lots of #[cfg(feature = "...")], which I don't like too much. (I don't remember why I didn't create a feature for the conv module, I think it is because all other features would depend on it.)

@mitchmindtree , since you probably know this crate better than I do, can you let me know which inter-dependencies make sense and which do not?

+387 -270

3 comments

13 changed files

PieterPenninckx

pr closed time in a day

issue closedRustAudio/sample

Split into several features

Currently, the sample crate has a high number of features, but if you just need a few of them, you need to compile them all.

Would you be open to a PR that defines a number of Cargo features that map to the features described in the README, so that a depending crate can just select the features it actually uses?

closed time in a day

PieterPenninckx

push eventmitchmindtree/sample

mitchmindtree

commit sha 221b81038c528bf3fc364a8ab5cc4b2e52f7dbfc

Final documentation cleanup before publishing

view details

push time in a day

push eventmitchmindtree/sample

mitchmindtree

commit sha 3c862f0f82a3a09a7affb0d3e87c08787ce608dc

Add an "all" feature that simplifies adding all features for each crate

view details

push time in a day

push eventmitchmindtree/sample

mitchmindtree

commit sha 3aaa3a9f6e70a05cd4f0bd346c62d1b50c8d4630

Add implementation of `Frame` for primitive types implementing `Sample` This greatly simplifies working with monophonic signals, as we no longer have to use a fixed size array of one element everywhere.

view details

push time in a day

push eventmitchmindtree/sample

mitchmindtree

commit sha 4487809a725a4a62244d3db5a91f259b774c071e

Add implementation of `Frame` for primitive types implementing `Sample` This greatly simplifies working with monophonic signals, as we no longer have to use a fixed size array of one element everywhere.

view details

push time in a day

push eventmitchmindtree/sample

mitchmindtree

commit sha 4819b5e0d37028945f265b8c7c66d7ff23dc4352

Add implementation of `Frame` for primitive types implementing `Sample` This greatly simplifies working with monophonic signals, as we no longer have to use a fixed size array of one element everywhere.

view details

push time in a day

push eventmitchmindtree/sample

mitchmindtree

commit sha 3a2113cef8bdfedc55fd5104d87412fe55ac6579

Remove equilibrium, identity and n_channels in favour of consts Makes the following changes: - `FloatSample::identity` -> `FloatSample::IDENTITY` - `Sample::equilibrium` -> `Sample::EQUILIBRIUM` - `Sample::identity` -> `Sample::IDENTITY` - `Frame::equilibrium` -> `Frame::EQUILIBRIUM` - `Frame::identity` -> `Frame::IDENTITY` - `Frame::n_channels` -> `Frame::CHANNELS`

view details

push time in a day

issue openedRustAudio/sample

Feature-gate sample newtypes (e.g. `I24`, `I48`, etc).

These should likely be opt-in features, as they are unneeded in the general case.

created time in a day

push eventmitchmindtree/sample

mitchmindtree

commit sha c8baad6414f2c21aefeb558fe1d55c591f5dbaa5

Remove potentially unsafe uninitialized ring_buffer constructors

view details

push time in a day

push eventmitchmindtree/sample

mitchmindtree

commit sha 13cd0c240cfac2d1f8b54b2bf05e5455bcbba2c0

Improve flexibility of the **Window** trait This allows for **Window** trait implementations to be more specific about the supported phase and output amplitude types of the implementation. The Hanning and Rectangle implementations currently remain generic, however we should consider restricting their implementations to floating point sample types in order to not hide the intermediate conversions that are required.

view details

push time in a day

push eventmitchmindtree/sample

mitchmindtree

commit sha fecf1f03a58bf6be5898a0df29b5ef120974a594

Rename all-features-no-std to all-no-std. Add docs about no_std.

view details

push time in a day

issue openedRustAudio/sample

Once stabilised, use the `doc_cfg` feature to automatically tag items with their required features in documentation

See here for info about the attribute.

I tried to get this going as a part of #120, however it seems that the attribute is ignored within crate dependencies. That is, when documenting dasp, the re-exported dependencies did not provide any information about their own features, only providing tags for the dasp-level features.

There's an issue following development of the feature here https://github.com/rust-lang/rust/issues/43781.

created time in a day

push eventmitchmindtree/sample

mitchmindtree

commit sha e09f785ad2b64266c5b8596b1f49868c8dca9d55

Update and improve docs for all crates. Add optional feature docs.

view details

mitchmindtree

commit sha cd77d58c1bf291163b6f26e2243c1b06f48f1430

Rename all-features-no-std to all-no-std. Add docs about no_std.

view details

push time in a day

issue openedRustAudio/sample

Add a `equilibrium_padded()` constructor to each of the interpolators.

Currently all interpolator implementations require being constructed with the initial samples used for inteprolation. In some cases, it might be more convenient to just construct the interpolator with equilibrium values to begin to avoid the need for the user to sample from the source signal.

created time in a day

push eventmitchmindtree/sample

mitchmindtree

commit sha e2d1b15f4a1cc43fe2d0258642dbcf382353aad8

Add missing no_std attr to dasp

view details

mitchmindtree

commit sha 06d8822b94870de3943c85e29dccf037f25dac70

Enable all features for dasp_ring_buffer docs.rs metadata

view details

mitchmindtree

commit sha 52b60e44a894f3eb08bcf9f190257b451f2afd57

Add a CHANGELOG

view details

push time in 2 days

push eventmitchmindtree/sample

mitchmindtree

commit sha 27590daf71bd95fc447deec9694ea6f11648af1b

Prepare crates for publishing under version 0.11.0. Rather than starting from version 0.1.0, I thought it would make sense for versioning to continue on from where the `sample` crate left off.

view details

mitchmindtree

commit sha 8a62a9844b66e3ce8456153929a052e304bf5aca

Complete missing entries from new dasp cargo manifests

view details

push time in 2 days

push eventmitchmindtree/sample

mitchmindtree

commit sha 895d25fdfb48787f1b9979119432aedcf0c19743

Fix dasp_frame mul_amp example

view details

push time in 2 days

push eventmitchmindtree/sample

mitchmindtree

commit sha 5f38099f07ca4709e60057665ad1f598870aa462

Add action status badge to top of top-level README

view details

mitchmindtree

commit sha 32776adda61c9a9241f0ddef9b69656a0fbb7deb

Remove remaining readme content from dasp_sample to top-level

view details

push time in 2 days

push eventmitchmindtree/sample

mitchmindtree

commit sha 6090e7f9f14721a1553da73899e1efae6b3acd88

Formatting and link fixes for README

view details

push time in 2 days

push eventmitchmindtree/sample

mitchmindtree

commit sha d5b5f2376f9ff7a25e1a95387f4a64e0153fc52d

Remove resampled wav from repo. Add to gitignore.

view details

push time in 2 days

push eventmitchmindtree/sample

mitchmindtree

commit sha f35a13453a893a28033cae3a0576faeac30257ea

Add dependency graph image to assets directory

view details

mitchmindtree

commit sha 5e0a1df2c8cfdb35faf4e7a79af843c530de1a8f

Update top-level README with info on included crates and no_std

view details

mitchmindtree

commit sha 4252cfa3730e6cd6f6ac601cdc14654c2f426444

Run cargo fmt on whole repository

view details

mitchmindtree

commit sha bb73ff66069add3aaf0f0c0e3c981408c02f73ad

Use nightly for no_std CI builds. Fix no-default-features tests.

view details

push time in 2 days

push eventmitchmindtree/sample

mitchmindtree

commit sha bd200767758661d77864ce89b4731c40e986b223

Add `all-features-no-std` features. Remove travis in favour of workflow Also adds auto-publishing when pushing to master and more thorough testing of different combinations of features and no_std.

view details

push time in 2 days

push eventmitchmindtree/sample

mitchmindtree

commit sha f948eca0d58f53e9ce7ed712388fecee2721a7c6

Remove portaudio from examples in favour of cpal

view details

mitchmindtree

commit sha d5d16a235c501abc73e2032bf21a2d3b0ab93def

Add `all-features-no-std` features. Remove travis in favour of workflow Also adds auto-publishing when pushing to master and more thorough testing of different combinations of features and no_std.

view details

push time in 2 days

PR opened RustAudio/sample

Rename `sample` to `dasp`. Split features into multiple crates.

This PR is based on @PieterPenninckx's great work in #116 and some of the past discussion that has occurred around improving the modularity of thesample crate. Having the crate split into features as in #116 made it easier for me to identify how to untangle the various modules into independent crates.

sample -> dasp

The direction of splitting up the crate into multiple sub crates has been on my mind for a long time, though the name sample always seemed unsuitable to as an umbrella term for the sub-crates of the project. After spending a bit of time throwing around different acronyms and abbreviations, @JoshuaBatty suggested dasp for digital audio signal processing. I think it rolls off the tongue pretty well!

Repo structure

The repository is now structured as a workspace consisting of a suite of subcrates. The dasp crate is the top-level crate, re-exporting each of the sub-crates and providing features that map not only to each of the sub-crates, but also to each of the sub-crate features too.

TODO

I thought I'd post this PR now to allow for feedback and thoughts. That said, there are still a few things I'd like to address before landing this:

  • [ ] Remove travis-ci in favour of github workflow CI with auto-publishing and a nice way of testing feature set permutations and with/without std.
  • [ ] Port synth.rs and play_wav.rs examples from portaudio to cpal.
  • [ ] Add CHANGELOG wich section on migrating from sample -> dasp.
  • [ ] Complete the "crates" table within the top-level README.
  • [ ] Add a graphviz png of the dasp dependency tree to the README.
  • [ ] Add a note to the docs of feature-gated items specifying required features.
  • [ ] Publish a new version of sample with a README notice about switching to dasp.

There are many other items I'd like to address, but they are likely best left for future PRs.

cc @PieterPenninckx, @andrewcsmith

Closes #116. Closes #112.

+3234 -3200

0 comment

71 changed files

pr created time in 2 days

create barnchmitchmindtree/sample

branch : dasp

created branch time in 2 days

issue commentnannou-org/nannou

Example draw_capture panics when running

Thanks for the issue @wataru358!

Unfortunately I'm unable to recreate this issue on my Linux laptop - both examples seem to behave as expected even when moving the mouse around and resizing the window slightly (though if I resize too much I run into #491).

Could you provide a little info about what platform you're on and your GPU? Also if you have the time, could you possibly run the examples again, but this time with the RUST_BACKTRACE=1 environment variable prefixed and post the output here? The back trace might help to hone in on the problem.

wataru358

comment created time in 2 days

issue commentRustAudio/cpal

[Question] How to record audio from input and stream to output?

@DuckerMan the examples/feedback.rs example is aimed at demonstrating how to achieve this. Ideally we'll eventually support duplex streams #349 but until then this approach should work for a lot of cases.

If you have tried running the example and it is has failed to compile or produced some kind of error, could you provide the error output and some details about which platform you're testing on etc so that we may try and recreate the issue?

DuckerMan

comment created time in 3 days

delete branch mitchmindtree/nannou

delete branch : draw_bgl

delete time in 4 days

push eventnannou-org/nannou

mitchmindtree

commit sha 7a8347acef133bf22665d265a9989b44a720f2fa

Separate bind group layout creation from render pipeline creation This fixes a bug where the draw render pass would occasionally attempt to generate a draw command with a bind group and render pipeline that refer to separate yet identical bind group layouts. Closes #612.

view details

mitchmindtree

commit sha f521a3c66960fd61a53ab0b9ab15d6582570c3f8

Merge pull request #613 from mitchmindtree/draw_bgl Separate bind group layout creation from render pipeline creation

view details

push time in 4 days

PR merged nannou-org/nannou

Separate bind group layout creation from render pipeline creation

This fixes a bug where the draw render pass would occasionally attempt to generate a draw command with a bind group and render pipeline that refer to separate yet identical bind group layouts.

Closes #612.

+16 -18

0 comment

1 changed file

mitchmindtree

pr closed time in 4 days

issue closednannou-org/nannou

Example draw_blend does not run

Hi, I'm pretty new to Rust and Nannou, and really looking forward to working with this!

Steps to reproduce:

  • Install rust, rustup, etc per doc
  • do cargo run --release --example draw_blend

Expected:

  • example runs

Actual:

  • rust window quits and cli gets error message

Log:

bash:nannou username$ RUST_BACKTRACE=full cargo run --example draw_blend
   Compiling libc v0.2.70
   Compiling autocfg v1.0.0
   Compiling cfg-if v0.1.10
   Compiling proc-macro2 v1.0.17
   Compiling unicode-xid v0.2.0
   Compiling syn v1.0.23
   Compiling bitflags v1.2.1
   Compiling byteorder v1.3.4
   Compiling lazy_static v1.4.0
   Compiling maybe-uninit v2.0.0
   Compiling log v0.4.8
   Compiling scopeguard v1.1.0
   Compiling memchr v2.3.3
   Compiling getrandom v0.1.14
   Compiling core-foundation-sys v0.7.0
   Compiling rand_core v0.4.2
   Compiling vec_map v0.8.2
   Compiling block v0.1.6
   Compiling serde v1.0.110
   Compiling adler32 v1.0.4
   Compiling foreign-types-shared v0.1.1
   Compiling rustc-serialize v0.3.24
   Compiling ppv-lite86 v0.2.8
   Compiling autocfg v0.1.7
   Compiling arrayvec v0.5.1
   Compiling glob v0.2.11
   Compiling regex v0.2.11
   Compiling ucd-util v0.1.8
   Compiling slab v0.4.2
   Compiling typenum v1.12.0
   Compiling libloading v0.4.3
   Compiling unicode-xid v0.1.0
   Compiling utf8-ranges v1.0.4
   Compiling rayon-core v1.7.0
   Compiling smallvec v1.4.0
   Compiling unicode-width v0.1.7
   Compiling siphasher v0.3.3
   Compiling strsim v0.8.0
   Compiling atom v0.3.5
   Compiling ansi_term v0.11.0
   Compiling fixedbitset v0.1.9
   Compiling bindgen v0.32.3
   Compiling lzw v0.10.0
   Compiling copyless v0.1.4
   Compiling arrayref v0.3.6
   Compiling proc-macro-nested v0.1.4
   Compiling color_quant v1.0.1
   Compiling byte-tools v0.2.0
   Compiling peeking_take_while v0.1.2
   Compiling either v1.5.3
   Compiling piston-float v0.3.0
   Compiling range-alloc v0.1.0
   Compiling futures-core v0.3.5
   Compiling ryu v1.0.4
   Compiling rustc-hash v1.1.0
   Compiling instant v0.1.4
   Compiling stable_deref_trait v1.1.1
   Compiling proc-macro-hack v0.5.15
   Compiling crc32fast v1.2.0
   Compiling once_cell v1.4.0
   Compiling futures-sink v0.3.5
   Compiling fake-simd v0.1.2
   Compiling linked-hash-map v0.5.3
   Compiling scoped_threadpool v0.1.9
   Compiling same-file v1.0.6
   Compiling fnv v1.0.7
   Compiling pin-utils v0.1.0
   Compiling futures-io v0.3.5
   Compiling failure_derive v0.1.8
   Compiling cgmath v0.17.0
   Compiling gimli v0.21.0
   Compiling itoa v0.4.5
   Compiling remove_dir_all v0.5.2
   Compiling core-foundation-sys v0.6.2
   Compiling bytemuck v1.2.0
   Compiling anymap v0.12.1
   Compiling dispatch v0.2.0
   Compiling fixedbitset v0.2.0
   Compiling rustc-demangle v0.1.16
   Compiling cpal v0.11.0
   Compiling object v0.19.0
   Compiling find_folder v0.3.0
   Compiling notosans v0.1.0
   Compiling conrod_winit v0.70.0
   Compiling interpolation v0.1.0
   Compiling itertools v0.4.19
   Compiling sample v0.9.1
   Compiling claxon v0.4.2
   Compiling alac v0.3.3
   Compiling hound v3.4.0
   Compiling sample v0.10.0
   Compiling thread_local v0.3.6
   Compiling lock_api v0.3.4
   Compiling foreign-types v0.3.2
   Compiling inflate v0.3.4
   Compiling miniz_oxide v0.3.6
   Compiling inflate v0.4.5
   Compiling rand_core v0.3.1
   Compiling num-traits v0.2.11
   Compiling num-integer v0.1.42
   Compiling crossbeam-utils v0.7.2
   Compiling num-iter v0.1.40
   Compiling memoffset v0.5.4
   Compiling crossbeam-epoch v0.8.2
   Compiling num-bigint v0.2.6
   Compiling num-rational v0.2.4
   Compiling num-complex v0.2.4
   Compiling indexmap v1.3.2
   Compiling regex-syntax v0.5.6
   Compiling proc-macro2 v0.2.3
   Compiling rand_pcg v0.1.2
   Compiling rand_chacha v0.1.1
   Compiling rand v0.6.5
   Compiling textwrap v0.11.0
   Compiling hibitset v0.6.3
   Compiling phf_shared v0.8.0
   Compiling petgraph v0.4.13
   Compiling clang-sys v0.21.2
   Compiling block-buffer v0.3.3
   Compiling piston-viewport v0.5.0
   Compiling gif v0.9.2
   Compiling gif v0.10.3
   Compiling owning_ref v0.3.3
   Compiling futures-channel v0.3.5
   Compiling futures-task v0.3.5
   Compiling walkdir v2.3.1
   Compiling storage-map v0.2.0
   Compiling rand_isaac v0.1.1
   Compiling rand_xorshift v0.1.1
   Compiling rand_hc v0.1.0
   Compiling addr2line v0.12.1
   Compiling quote v0.4.2
   Compiling phf v0.8.0
   Compiling daggy v0.5.0
   Compiling daggy v0.6.0
   Compiling log v0.3.9
   Compiling smallvec v0.6.13
   Compiling aho-corasick v0.6.10
   Compiling fxhash v0.2.1
   Compiling stb_truetype v0.3.1
   Compiling deflate v0.7.20
   Compiling deflate v0.8.4
   Compiling tiff v0.4.0
   Compiling ogg v0.5.1
   Compiling rosc v0.1.6
   Compiling ether-dream v0.2.5
   Compiling caf v0.1.0
   Compiling quote v1.0.6
   Compiling jobserver v0.1.21
   Compiling rand v0.4.6
   Compiling malloc_buf v0.0.6
   Compiling num_cpus v1.13.0
   Compiling raw-window-handle v0.3.3
   Compiling core-foundation v0.7.0
   Compiling memchr v1.0.2
   Compiling parking_lot_core v0.7.2
   Compiling atty v0.2.14
   Compiling which v1.0.5
   Compiling rand_os v0.1.3
   Compiling rand_jitter v0.1.4
   Compiling fsevent-sys v3.0.0
   Compiling filetime v0.2.10
   Compiling rand v0.5.6
   Compiling backtrace v0.3.48
   Compiling lewton v0.7.0
   Compiling nannou_osc v0.14.0 (/Users/username/personal/nannou/nannou_osc)
   Compiling generic-array v0.9.0
   Compiling png v0.16.3
   Compiling cc v1.0.54
   Compiling threadpool v1.8.1
   Compiling gfx-hal v0.5.0
   Compiling rand_core v0.5.1
   Compiling nom v3.2.1
   Compiling clap v2.33.1
   Compiling fsevent v2.0.1
   Compiling parking_lot v0.10.2
   Compiling core-graphics v0.19.0
   Compiling crossbeam-queue v0.2.1
   Compiling crossbeam-channel v0.4.2
   Compiling parking_lot_core v0.2.14
   Compiling rand v0.3.23
   Compiling petgraph v0.5.1
   Compiling digest v0.7.6
   Compiling approx v0.3.2
   Compiling euclid v0.20.12
   Compiling ordered-float v1.0.2
   Compiling num-traits v0.1.43
   Compiling num-complex v0.1.43
   Compiling sid v0.6.1
   Compiling pennereq v0.3.1
   Compiling audrey v0.2.0
   Compiling cmake v0.1.44
   Compiling env_logger v0.4.3
   Compiling rand_chacha v0.2.2
   Compiling rand_pcg v0.2.1
   Compiling objc_exception v0.1.2
   Compiling spirv_cross v0.20.0
   Compiling cexpr v0.2.3
   Compiling crossbeam-deque v0.7.3
   Compiling parking_lot v0.4.8
   Compiling sha2 v0.7.1
   Compiling num-bigint v0.1.44
   Compiling enum_primitive v0.1.1
   Compiling lasy v0.4.1
   Compiling lyon_geom v0.15.3
   Compiling rand v0.7.3
   Compiling rusttype v0.8.3
   Compiling chashmap v2.2.2
   Compiling glsl-to-spirv v0.1.7
   Compiling png v0.11.0
   Compiling synstructure v0.12.3
   Compiling num-rational v0.1.42
   Compiling gfx-backend-empty v0.5.0
   Compiling gfx-descriptor v0.1.0
   Compiling gfx-memory v0.1.3
   Compiling lyon_path v0.15.2
   Compiling notify v5.0.0-pre.2
   Compiling rayon v1.3.0
   Compiling phf_generator v0.8.0
   Compiling tempfile v3.1.0
   Compiling num v0.1.42
   Compiling num v0.2.1
   Compiling lyon_tessellation v0.15.8
   Compiling lyon_algorithms v0.15.0
   Compiling phf_codegen v0.8.0
   Compiling envelope v0.8.1
   Compiling serde_derive v1.0.110
   Compiling peek-poke-derive v0.2.1
   Compiling thiserror-impl v1.0.19
   Compiling pin-project-internal v0.4.17
   Compiling conrod_derive v0.70.0
   Compiling futures-macro v0.3.5
   Compiling zerocopy-derive v0.2.0
   Compiling palette_derive v0.5.0
   Compiling palette v0.5.0
   Compiling lyon v0.15.8
   Compiling peek-poke v0.2.0
   Compiling jpeg-decoder v0.1.19
   Compiling thiserror v1.0.19
   Compiling zerocopy v0.3.0
   Compiling wgpu-types v0.5.1
   Compiling image v0.18.0
   Compiling image v0.23.4
   Compiling failure v0.1.8
   Compiling pin-project v0.4.17
   Compiling ilda-idtf v0.1.0
   Compiling futures-util v0.3.5
   Compiling nannou_laser v0.14.3 (/Users/username/personal/nannou/nannou_laser)
   Compiling noise v0.6.0
   Compiling coreaudio-sys v0.2.2
   Compiling objc v0.2.7
   Compiling cocoa v0.20.1
   Compiling objc_id v0.1.1
   Compiling core-video-sys v0.1.4
   Compiling objc-foundation v0.1.1
   Compiling copypasta v0.6.3
   Compiling futures-executor v0.3.5
   Compiling futures v0.3.5
   Compiling metal v0.18.0
   Compiling winit v0.22.2
   Compiling pistoncore-input v0.24.0
   Compiling serde_json v1.0.53
   Compiling toml v0.5.6
   Compiling pitch_calc v0.12.0
   Compiling time_calc v0.13.0
   Compiling isf v0.1.0 (https://github.com/nannou-org/isf#99424e5b)
   Compiling conrod_core v0.70.0
   Compiling nannou_timeline v0.14.0 (/Users/username/personal/nannou/nannou_timeline)
   Compiling gfx-auxil v0.4.0
   Compiling gfx-backend-metal v0.5.2
   Compiling hotglsl v0.1.0 (https://github.com/nannou-org/hotglsl#0066deaf)
   Compiling wgpu-core v0.5.5
   Compiling coreaudio-rs v0.9.1
   Compiling nannou_audio v0.14.0 (/Users/username/personal/nannou/nannou_audio)
   Compiling wgpu-native v0.5.0
   Compiling wgpu v0.5.0
   Compiling conrod_wgpu v0.70.0
   Compiling nannou v0.14.1 (/Users/username/personal/nannou/nannou)
   Compiling nannou_isf v0.1.0 (/Users/username/personal/nannou/nannou_isf)
   Compiling examples v0.1.0 (/Users/username/personal/nannou/examples)
    Finished dev [unoptimized + debuginfo] target(s) in 4m 59s
     Running `target/debug/examples/draw_blend`
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: IncompatibleBindGroup. The current render pipeline has a layout which is incompatible with a currently set bind group. They first differ at entry index 2.', /Users/username/.cargo/registry/src/github.com-1ecc6299db9ec823/wgpu-core-0.5.5/src/command/render.rs:1150:21
stack backtrace:
   0:        0x1073fd4ff - backtrace::backtrace::libunwind::trace::hfff3154c85fa162b
                               at /Users/runner/.cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.44/src/backtrace/libunwind.rs:86
   1:        0x1073fd4ff - backtrace::backtrace::trace_unsynchronized::h4a9920525cd627b4
                               at /Users/runner/.cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.44/src/backtrace/mod.rs:66
   2:        0x1073fd4ff - std::sys_common::backtrace::_print_fmt::h972e000d0e4ed1fa
                               at src/libstd/sys_common/backtrace.rs:78
   3:        0x1073fd4ff - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::hdfed66b3e2e8ce60
                               at src/libstd/sys_common/backtrace.rs:59
   4:        0x10741ab3e - core::fmt::write::h9de7b13cfaa80b03
                               at src/libcore/fmt/mod.rs:1063
   5:        0x1073faa67 - std::io::Write::write_fmt::h9197012b9d65a9a3
                               at src/libstd/io/mod.rs:1426
   6:        0x1073ff53a - std::sys_common::backtrace::_print::hb8e24d3c51344086
                               at src/libstd/sys_common/backtrace.rs:62
   7:        0x1073ff53a - std::sys_common::backtrace::print::h93407cb3f8a6ecb3
                               at src/libstd/sys_common/backtrace.rs:49
   8:        0x1073ff53a - std::panicking::default_hook::{{closure}}::h7b209cdc44c5777f
                               at src/libstd/panicking.rs:204
   9:        0x1073ff27c - std::panicking::default_hook::hf135bc502e6f77db
                               at src/libstd/panicking.rs:224
  10:        0x1073ffba8 - std::panicking::rust_panic_with_hook::h7967810bc33e523b
                               at src/libstd/panicking.rs:470
  11:        0x1073ff772 - rust_begin_unwind
                               at src/libstd/panicking.rs:378
  12:        0x10742ac6f - core::panicking::panic_fmt::h9eea9e4965bd189c
                               at src/libcore/panicking.rs:85
  13:        0x10742ab75 - core::option::expect_none_failed::ha68a01397bf24c9a
                               at src/libcore/option.rs:1211
  14:        0x106de2721 - core::result::Result<T,E>::unwrap::hd89496db367d7754
                               at /rustc/8d69840ab92ea7f4d323420088dd8c9775f180cd/src/libcore/result.rs:1003
  15:        0x106d7c53d - wgpu_core::command::render::<impl wgpu_core::hub::Global<G>>::command_encoder_run_render_pass::hc3447a58492b7868
                               at /Users/username/.cargo/registry/src/github.com-1ecc6299db9ec823/wgpu-core-0.5.5/src/command/render.rs:1150
  16:        0x106e0cef1 - wgpu_render_pass_end_pass
                               at /Users/username/.cargo/registry/src/github.com-1ecc6299db9ec823/wgpu-native-0.5.0/src/command.rs:101
  17:        0x106cfb80f - <wgpu::RenderPass as core::ops::drop::Drop>::drop::hc4ade2a4aa812c7c
                               at /Users/username/.cargo/registry/src/github.com-1ecc6299db9ec823/wgpu-0.5.0/src/lib.rs:1542
  18:        0x106a6ab71 - core::ptr::drop_in_place::h59adb9db4017d025
                               at /rustc/8d69840ab92ea7f4d323420088dd8c9775f180cd/src/libcore/ptr/mod.rs:177
  19:        0x106a50415 - nannou::draw::renderer::Renderer::encode_render_pass::h4d6c69f5e2e74c38
                               at nannou/src/draw/renderer/mod.rs:894
  20:        0x106a5076a - nannou::draw::renderer::Renderer::render_to_frame::h7865cce5ba55ad38
                               at nannou/src/draw/renderer/mod.rs:934
  21:        0x106a99791 - nannou::app::<impl nannou::draw::Draw>::to_frame::ha3f6b8b71ab35196
                               at nannou/src/app.rs:911
  22:        0x106a0d129 - draw_blend::view::hd8ac65399e0463c3
                               at examples/draw/draw_blend.rs:86
  23:        0x106a23ddb - nannou::app::run_loop::{{closure}}::h3bb60fa7cbd82120
                               at /Users/username/personal/nannou/nannou/src/app.rs:1128
  24:        0x106a0dfd7 - <alloc::boxed::Box<F> as core::ops::function::FnMut<A>>::call_mut::hfb4cdcda8f2b21c9
                               at /rustc/8d69840ab92ea7f4d323420088dd8c9775f180cd/src/liballoc/boxed.rs:1024
  25:        0x106a25c13 - <winit::platform_impl::platform::app_state::EventLoopHandler<T> as winit::platform_impl::platform::app_state::EventHandler>::handle_nonuser_event::h6abe527ce1f2d8d4
                               at /Users/username/.cargo/registry/src/github.com-1ecc6299db9ec823/winit-0.22.2/src/platform_impl/macos/app_state.rs:71
  26:        0x106c96b7f - winit::platform_impl::platform::app_state::Handler::handle_nonuser_event::h3bd9676ddde3b5cd
  27:        0x106c98abd - winit::platform_impl::platform::app_state::AppState::cleared::h76ef5267aaeef01f
  28:        0x106c91d5e - winit::platform_impl::platform::observer::control_flow_end_handler::h82333a14a9d98c18
  29:     0x7fff2ffc06d8 - <unknown>
  30:     0x7fff2ffc060d - <unknown>
  31:     0x7fff2ff62e57 - <unknown>
  32:     0x7fff2ff6266e - <unknown>
  33:     0x7fff2f1c11ab - <unknown>
  34:     0x7fff2f1c0ee5 - <unknown>
  35:     0x7fff2f1c0c76 - <unknown>
  36:     0x7fff2d55877d - <unknown>
  37:     0x7fff2d55746b - <unknown>
  38:     0x7fff2d551588 - <unknown>
  39:        0x10736fed6 - <() as objc::message::MessageArguments>::invoke::h5afc7958099737e5
                               at /Users/username/.cargo/registry/src/github.com-1ecc6299db9ec823/objc-0.2.7/src/message/mod.rs:128
  40:        0x10736cc9d - objc::message::platform::send_unverified::h285c41b96c3de9d8
                               at /Users/username/.cargo/registry/src/github.com-1ecc6299db9ec823/objc-0.2.7/src/message/apple/mod.rs:27
  41:        0x106a0f906 - objc::message::send_message::hc853223210c49bcb
                               at /Users/username/.cargo/registry/src/github.com-1ecc6299db9ec823/objc-0.2.7/src/message/mod.rs:178
  42:        0x106a0f906 - winit::platform_impl::platform::event_loop::EventLoop<T>::run_return::hc79b5b5d2e4fb4d0
                               at /Users/username/personal/nannou/<::objc::macros::msg_send macros>:15
  43:        0x106a0fb64 - winit::platform_impl::platform::event_loop::EventLoop<T>::run::hdb43652d7c66792d
                               at /Users/username/.cargo/registry/src/github.com-1ecc6299db9ec823/winit-0.22.2/src/platform_impl/macos/event_loop.rs:89
  44:        0x106a19ae3 - winit::event_loop::EventLoop<T>::run::h51cfbab45bb981d4
                               at /Users/username/.cargo/registry/src/github.com-1ecc6299db9ec823/winit-0.22.2/src/event_loop.rs:149
  45:        0x106a23209 - nannou::app::run_loop::hde8b0c8b55e8116f
                               at /Users/username/personal/nannou/nannou/src/app.rs:1020
  46:        0x106a1cbde - nannou::app::Builder<M,E>::run::hb8f4dac19fefa6b3
                               at /Users/username/personal/nannou/nannou/src/app.rs:471
  47:        0x106a1cd11 - nannou::app::SketchBuilder<E>::run::he5b80757901b9ae2
                               at /Users/username/personal/nannou/nannou/src/app.rs:496
  48:        0x106a0c2b1 - draw_blend::main::hf29870645e4656ef
                               at examples/draw/draw_blend.rs:4
  49:        0x106a0fbfe - std::rt::lang_start::{{closure}}::h394a5c713e84ced5
                               at /rustc/8d69840ab92ea7f4d323420088dd8c9775f180cd/src/libstd/rt.rs:67
  50:        0x1073ff678 - std::rt::lang_start_internal::{{closure}}::hab79accac7befc7d
                               at src/libstd/rt.rs:52
  51:        0x1073ff678 - std::panicking::try::do_call::he58e98df0f664580
                               at src/libstd/panicking.rs:303
  52:        0x107401dbb - __rust_maybe_catch_panic
                               at src/libpanic_unwind/lib.rs:86
  53:        0x10740007a - std::panicking::try::h1c15a2595ce4d309
                               at src/libstd/panicking.rs:281
  54:        0x10740007a - std::panic::catch_unwind::h06858616dd2b84f7
                               at src/libstd/panic.rs:394
  55:        0x10740007a - std::rt::lang_start_internal::hfa21381d8ff23689
                               at src/libstd/rt.rs:51
  56:        0x106a0fbe1 - std::rt::lang_start::hf84070b83d2a38fd
                               at /rustc/8d69840ab92ea7f4d323420088dd8c9775f180cd/src/libstd/rt.rs:67
  57:        0x106a0d612 - draw_blend::view::hd8ac65399e0463c3

My guess is this is related to this:https://github.com/gfx-rs/wgpu-rs/commit/02f7ac9c02bf2e7313fa1b17a996b1a882a39a27

There are couple more of this error in example. I will add that info as I test them to run.

closed time in 4 days

wataru358

PR opened nannou-org/nannou

Separate bind group layout creation from render pipeline creation

This fixes a bug where the draw render pass would occasionally attempt to generate a draw command with a bind group and render pipeline that refer to separate yet identical bind group layouts.

Closes #612.

+16 -18

0 comment

1 changed file

pr created time in 4 days

create barnchmitchmindtree/nannou

branch : draw_bgl

created branch time in 4 days

issue commentnannou-org/nannou

Example draw_blend does not run

This bug seems to be caused by the switch in render pipeline that is necessary in order to switch blend modes. I believe the issue is that currently, each time a pipeline is constructed, a new bind group layout is also constructed. In this example, when the blend mode is changed the render pipeline is changed and in turn a new bind group layout is created. In this case, the bind group layout is identical to the bind group layout in the previous render pipeline however it seems that the layout being equivalent is not enough. It seems that the bind group layout must have some unique identifier that must exactly match that with which the bind group itself is created.

I think the solution here is to separate the creation of bind group layouts from the creation of render pipelines, allowing a pipeline to re-use a layout in the case that only the blend mode has changed (as in our case). This should ensure the current render pipeline and bind group always refer to the same bind group layout instance.

wataru358

comment created time in 4 days

issue commentnannou-org/nannou

Example draw_blend does not run

Thanks a lot for the report @wataru358! I think this is likely an error I must have introduced in #594. wgpu 0.5 introduces some tighter restrictions on bind group and pipeline layouts, I thought I had addressed them but I must have missed something. I'll investigate now!

wataru358

comment created time in 4 days

issue closedRustAudio/cpal

Provide proper range of available sample rates in webaudio backend

Currently 44.1khz is hard-coded throughout the implementation. However, an inline comment mentions that browsers must support all sample rates from 8khz to 96khz.

closed time in 4 days

mitchmindtree

issue closedRustAudio/cpal

Provide proper range of available channels in webaudio backend

Currently two channels is hard-coded throughout the implementation. However, an inline comment mentions that browsers must support between 1 and 32 channels. We should investigate and see if there's an API for acquiring the number of channels available on the device targeted by the browser, as e.g. there's no point allowing the selection of 32 channels if only two are available.

closed time in 4 days

mitchmindtree

delete branch mitchmindtree/cpal

delete branch : webaudio_config

delete time in 4 days

push eventRustAudio/cpal

mitchmindtree

commit sha 1dfdeace25b6d61a55714c76795b5b7f09e789f0

Add implementation of supported stream configs for webaudio The `supported_stream_configs` method now returns the range of configurations that are required to be supported for `BaseAudioContext.createBuffer()` as mentioned here: https://developer.mozilla.org/en-US/docs/Web/API/BaseAudioContext/createBuffer That is, valid stream configurations are now considered to be any configuration that has: - 1 <= channel_count <= 32 and - 8khz <= sample_rate <= 96khz - sample_format == f32 Closes #410. Closes #411.

view details

mitchmindtree

commit sha f03fd69b654d554ca9a7d4cd4b680354ca058af6

[webaudio] Return Err instead of panicking on input device requests Currently we are yet to implement input stream support for CPAL's webaudio host. Instead of panicking, we should return an error, None or empty iterator in order to let the user write well behaved cross-platform apps and notify the user accordingly rather than crashing.

view details

mitchmindtree

commit sha 5fa5ce593d3692b2ff16f9585681f75fb27d8943

Merge pull request #415 from mitchmindtree/webaudio_config Add implementation of supported stream configs for webaudio

view details

push time in 4 days

push eventRustAudio/cpal

ely-uf

commit sha d9136708e4275eb7058d6d0858d739c3489cd4a5

Fix CoreAudio warnings. 1) warning: use of deprecated item 'std::error::Error::description': use the Display impl or to_string() 2) warning: unnecessary `unsafe` block 3) warning: field is never read: `device_id`

view details

mitchmindtree

commit sha 713eddd89aab958eae964da5d78e0c96146eb72e

Merge pull request #419 from ely-uf/chore/cleanup-coreaudio-warnings Fix CoreAudio warnings.

view details

push time in 5 days

PR merged RustAudio/cpal

Fix CoreAudio warnings.

Hi, discovered 7 warnings issued by rustc 1.42.0 (b8cedc004 2020-03-09).

cargo build and cargo test run successfully with the changes in this PR.

The list of warnings fixed:

  1. warning: unnecessary unsafe block [L184]
  2. warning: use of deprecated item 'std::error::Error::description': use the Display impl or to_string() [L330, L817, L831, L846]
  3. warning: field is never read: device_id [L411]
+6 -5

1 comment

1 changed file

ely-uf

pr closed time in 5 days

pull request commentRustAudio/cpal

Fix CoreAudio warnings.

Thanks so much!

ely-uf

comment created time in 5 days

push eventmitchmindtree/cpal

mitchmindtree

commit sha f03fd69b654d554ca9a7d4cd4b680354ca058af6

[webaudio] Return Err instead of panicking on input device requests Currently we are yet to implement input stream support for CPAL's webaudio host. Instead of panicking, we should return an error, None or empty iterator in order to let the user write well behaved cross-platform apps and notify the user accordingly rather than crashing.

view details

push time in 5 days

push eventmitchmindtree/cpal

mitchmindtree

commit sha ff4da51c8b7e605a0914c42e162b8718445a3508

[webaudio] Return Err instead of panicking on input device requests Currently we are yet to implement input stream support for CPAL's webaudio host. Instead of panicking, we should return an error, None or empty iterator in order to let the user write well behaved cross-platform apps and notify the user accordingly rather than crashing.

view details

push time in 5 days

push eventRustAudio/cpal

dependabot[bot]

commit sha 24452e8cacae0fdf8339cb963e406efcd9278f8a

Bump acorn from 6.4.0 to 6.4.1 in /examples/wasm-beep Bumps [acorn](https://github.com/acornjs/acorn) from 6.4.0 to 6.4.1. - [Release notes](https://github.com/acornjs/acorn/releases) - [Commits](https://github.com/acornjs/acorn/compare/6.4.0...6.4.1) Signed-off-by: dependabot[bot] <support@github.com>

view details

mitchmindtree

commit sha 4a52f29c2a9a1988d37eb2a226db995521b6d636

Merge pull request #418 from RustAudio/dependabot/npm_and_yarn/examples/wasm-beep/acorn-6.4.1 Bump acorn from 6.4.0 to 6.4.1 in /examples/wasm-beep

view details

push time in 5 days

PR merged RustAudio/cpal

Bump acorn from 6.4.0 to 6.4.1 in /examples/wasm-beep dependencies

Bumps acorn from 6.4.0 to 6.4.1. <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/acornjs/acorn/commit/9a2e9b6678e243d66846b91179d650d28453e70c"><code>9a2e9b6</code></a> Mark version 6.4.1</li> <li><a href="https://github.com/acornjs/acorn/commit/90a9548ea0ce351b54f956e2c4ed27cca9631284"><code>90a9548</code></a> More rigorously check surrogate pairs in regexp validator</li> <li>See full diff in <a href="https://github.com/acornjs/acorn/compare/6.4.0...6.4.1">compare view</a></li> </ul> </details> <br />

Dependabot compatibility score

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


<details> <summary>Dependabot commands and options</summary> <br />

You can trigger Dependabot actions by commenting on this PR:

  • @dependabot rebase will rebase this PR
  • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
  • @dependabot merge will merge this PR after your CI passes on it
  • @dependabot squash and merge will squash and merge this PR after your CI passes on it
  • @dependabot cancel merge will cancel a previously requested merge and block automerging
  • @dependabot reopen will reopen this PR if it is closed
  • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
  • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
  • @dependabot use these labels will set the current labels as the default for future PRs for this repo and language
  • @dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language
  • @dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language
  • @dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language

You can disable automated security fix PRs for this repo from the Security Alerts page.

</details>

+3 -3

0 comment

1 changed file

dependabot[bot]

pr closed time in 5 days

push eventRustAudio/cpal

Tatsuyuki Ishi

commit sha 9dc0c04c95630125749098301f06f9579074a90d

Add wasm-beep example

view details

mitchmindtree

commit sha 4ef48cb8653c4661b3a0c6fbc700d96fe6f82f23

Add ishitatsuyuki's wasm-beep example This adds the `wasm-beep` example @ishitatsuyuki put together for testing webaudio support. The example helped me to better understand how to use the webaudio host and provided an easy way to test it, I'm sure other contributors/users might benefit in the same way. I guess in the future it would be nice if we could have some way of sharing the same code between wasm-target examples and native target examples. Still, I think it's beneficial to include this wasm-beep example in the meantime to have at least some kind of demonstration of how to use cpal with wasm. Are you happy for this to be added as is @ishitatsuyuki?

view details

mitchmindtree

commit sha 157dff0546dd9a07b97222fb365c40ce76a44c9a

Merge pull request #416 from mitchmindtree/wasm-beep Add ishitatsuyuki's wasm-beep example

view details

push time in 5 days

PR merged RustAudio/cpal

Add ishitatsuyuki's wasm-beep example

This adds the wasm-beep example @ishitatsuyuki put together for testing webaudio support. The example helped me to better understand how to use the webaudio host and provided an easy way to test it, I'm sure other contributors/users might benefit in the same way.

I guess in the future it would be nice if we could have some way of sharing the same code between wasm-target examples and native target examples. Still, I think it's beneficial to include this wasm-beep example in the meantime to have at least some kind of demonstration of how to use cpal with wasm.

Are you happy for this to be added as is @ishitatsuyuki?

+6344 -0

1 comment

9 changed files

mitchmindtree

pr closed time in 5 days

PR opened RustAudio/cpal

Add ishitatsuyuki's wasm-beep example

This adds the wasm-beep example @ishitatsuyuki put together for testing webaudio support. The example helped me to better understand how to use the webaudio host and provided an easy way to test it, I'm sure other contributors/users might benefit in the same way.

I guess in the future it would be nice if we could have some way of sharing the same code between wasm-target examples and native target examples. Still, I think it's beneficial to include this wasm-beep example in the meantime to have at least some kind of demonstration of how to use cpal with wasm.

Are you happy for this to be added as is @ishitatsuyuki?

+6344 -0

0 comment

9 changed files

pr created time in 5 days

push eventmitchmindtree/cpal

mitchmindtree

commit sha 4ef48cb8653c4661b3a0c6fbc700d96fe6f82f23

Add ishitatsuyuki's wasm-beep example This adds the `wasm-beep` example @ishitatsuyuki put together for testing webaudio support. The example helped me to better understand how to use the webaudio host and provided an easy way to test it, I'm sure other contributors/users might benefit in the same way. I guess in the future it would be nice if we could have some way of sharing the same code between wasm-target examples and native target examples. Still, I think it's beneficial to include this wasm-beep example in the meantime to have at least some kind of demonstration of how to use cpal with wasm. Are you happy for this to be added as is @ishitatsuyuki?

view details

push time in 5 days

create barnchmitchmindtree/cpal

branch : wasm-beep

created branch time in 5 days

issue commentRustAudio/cpal

24 / 32 bit audio - Support for more `SampleFormat` variants and `Sample` types

Thanks for the issue @julientregoat !

Yeah CPAL's current set of supported SampleFormats is quite minimal, I think it's a good idea to start thinking about what other variants we want to add to the SampleFormat type.

I32 is another major one that we should add - the ASIO backend often only supports this format and we currently have a very hacky way of hacking around this.

W.r.t 24-bit streams, what layout specifically does the data you have in mind? I imagine it might be a bit trickier to support formats that don't directly correlate with Rust primitive types, but should be doable if there's a good enough use-case. We have to start thinking about packed, unpacked and the justification of the sample data within unpacked formats, and how we might expose this sort of API to the user. There's a nice description of the various possible layouts for 24-bit audio data here.

julientregoat

comment created time in 5 days

issue commentnannou-org/nannou

Bug when using multiple textures

Thanks for the issue @chrisburnor!

I think perhaps this has been fixed on master by #594 which overhauled the way the draw::Renderer creates commands for the render pass.

Sure enough, if I run your snippet above on master (with some small modifications to get it compiling/running locally with local images) it seems to be working with the two textures displaying one on top of the other:

Screenshot from 2020-05-25 13-54-26

In case you're interested, you can see what other changes are yet to be published to crates.io under the "Unreleased" section of the changelog here.

Perhaps we should publish 0.15 soon as there are quite a few changes pending there now!

chrisburnor

comment created time in 5 days

issue commentRustAudio/cpal

Provide proper range of available sample rates in webaudio backend

Hi @julientregoat, thanks for offering to dive into this! I thought I'd go ahead and implement this today as I plan to move on to getting input stream support working but wanted to address this issue first. Please feel welcome to take a look at #415 and provide any feedback.

Re 192khz, I'm hesitant to support this as the webaudio spec seems to only require that webaudio implementers support 8khz to 96khz. I haven't looked into it too thoroughly, but I imagine there might be an API out there that allows for querying what the actual supported sample rates are (rather than just this minimum set). If so, and if the API is portable (implemented by all major webaudio hosts/browsers) a follow-up PR would be more than welcome!

mitchmindtree

comment created time in 6 days

PR opened RustAudio/cpal

Add implementation of supported stream configs for webaudio

The supported_stream_configs method now returns the range of configurations that are required to be supported for BaseAudioContext.createBuffer() as mentioned here:

https://developer.mozilla.org/en-US/docs/Web/API/BaseAudioContext/createBuffer

That is, valid stream configurations are now considered to be any configuration that has:

  • 1 <= channel_count <= 32 and
  • 8khz <= sample_rate <= 96khz
  • sample_format == f32

Closes #410. Closes #411.

+74 -49

0 comment

1 changed file

pr created time in 6 days

create barnchmitchmindtree/cpal

branch : webaudio_config

created branch time in 6 days

push eventmitchmindtree/daggy

mitchmindtree

commit sha 6e4da8f53f85287c1cd5ca9871b5c87fef9e37e3

Fix cargo publish action

view details

push time in 7 days

delete branch mitchmindtree/daggy

delete branch : update_petgraph

delete time in 7 days

push eventmitchmindtree/daggy

mitchmindtree

commit sha 73c82984a0cdc69ded364359e854bdf5c9f7fe21

Update to petgraph 0.5. Rename `stabledag` -> `stable_dag`. Also tidies up the serde feature a little by putting the serde implementations in submodules.

view details

mitchmindtree

commit sha e09cf17fcc3c5b14df937397fe334864baa2e930

Remove travis in favour of github actions. Update README. Also adds an auto-publish action and enables `--all-features` for docs.rs metadata.

view details

mitchmindtree

commit sha 7d0702d2067bca7bd53fb000e86e81230e0c86cf

Run rustfmt on repo

view details

mitchmindtree

commit sha 18a8cad89df7e6d864812177ea9a765a0e224b80

Publish 0.7

view details

mitchmindtree

commit sha 958c4839786593b409888a88cb8a05287496d219

Merge pull request #27 from mitchmindtree/update_petgraph Update to petgraph 0.5. Rename `stabledag` -> `stable_dag`. Add github workflow. Publish 0.7.

view details

push time in 7 days

PR merged mitchmindtree/daggy

Update to petgraph 0.5. Rename `stabledag` -> `stable_dag`. Add github workflow. Publish 0.7.

Also:

  • Update to edition 2018.
  • Tidies up the serde feature a little by putting the serde implementations in submodules.
  • Removes travis integration.
  • Adds an auto-publish action.
  • Enables --all-features for docs.rs metadata.
  • Runs rustfmt on repo.
  • Adds a formatting check for PRs.
+296 -187

0 comment

16 changed files

mitchmindtree

pr closed time in 7 days

issue closedmitchmindtree/daggy

Update petgraph and use StableGraph

Hello. I'm here, getting ready to use daggy in a project of mine, when I check Dag's documentation, and find out that removals may change indices. I looked around (docs.rs), and found that because daggy used petgraph 0.2.2, it missed out on petgraph 0.4.3's StableGraph.

I would like to propose updating, and building Dag off of StableGraph, in order to stablize indices.

closed time in 7 days

Jengamon

issue commentmitchmindtree/daggy

Update petgraph and use StableGraph

Closed via #21.

Jengamon

comment created time in 7 days

push eventmitchmindtree/daggy

mitchmindtree

commit sha 18a8cad89df7e6d864812177ea9a765a0e224b80

Publish 0.7

view details

push time in 7 days

push eventmitchmindtree/daggy

mitchmindtree

commit sha 7d0702d2067bca7bd53fb000e86e81230e0c86cf

Run rustfmt on repo

view details

push time in 7 days

PR opened mitchmindtree/daggy

Update to petgraph 0.5. Rename `stabledag` -> `stable_dag`. Add github workflow.

Also:

  • Tidies up the serde feature a little by putting the serde implementations in submodules.
  • Removes travis integration.
  • Adds an auto-publish action.
  • Enables --all-features for docs.rs metadata.
+182 -126

0 comment

12 changed files

pr created time in 7 days

create barnchmitchmindtree/daggy

branch : update_petgraph

created branch time in 7 days

create barnchmitchmindtree/nannou

branch : isf

created branch time in 7 days

issue openedredox-os/orbtk

Do you have plans to allow for custom input event loops / renderers?

For example, if I'm using winit in an existing project, would it be possible to add in an orbtk GUI and drive it forward by translating winit events to some orbtk input event type?

Similarly, does orbtk have a platform-agnostic rendering abstraction? Perhaps something like a mesh and some render commands? I'm curious if it's possible to write a custom renderer, e.g. as a wgpu render pass.

I noticed the goals of being cross-platform and modular, but I'm just trying to get a better gauge to what extent. Feel free to link me elsewhere if this has already been discussed!

created time in 7 days

issue commentnannou-org/nannou

`nannou_gui` - A native, more efficient, data-driven approach to UI compatible with future GUI editor plans.

Synchronising GUI and Application State

One design choice I've yet to resolve is how to handle the updating and synchronisation of state in general. This can be broken into two related problems:

  1. Allow changes in application state to update GUI state.
  2. Allow changes in GUI state to update application state.

In conrod this is generally handled automatically as widgets require being instantiated directly from application data on every update. The trade-off here is the performance issue of needing to update every widget every update, a large cost that we are trying to avoid in the new design.

Solution Research

Data-Driven (ala druid)

The druid library uses a data-driven approach not dissimilar to conrod where widgets are updated with a reference to the application state itself. It provides similar benefits, making it trivial to keep the GUI synchronised with application state and allowing the GUI to store slightly less state itself.

However, the druid API is different in the sense that it provides a reference to the previous application state as well. Druid also requires that application state implements Data, a druid trait that is almost identical to PartialEq, allowing to compare whether or not the previous state is equal to the current state. This provides an easy, cheap approach for determining whether or not Widget::update needs to be called for each widget each frame.

State updating occurs via a couple of methods:

  1. druid::Widget::update for updating the widget in response to some change in application state.
  2. druid::Widget::event for updating both the widget and application state in response to some application/window/user-input event.

One of the tricky requirements of the druid approach is the requirement for the Data and Clone implementations on all application state that must be visited by the GUI. This means even common standard collection types like Strings, Vecs and HashMaps can be expensive to maintain, and that in general the user would benefit by understanding how to structure their application with immutable data structures (e.g. the im crate).

Another requirement to consider is that widget trait implementations are templated on the type of data that the widgets are compatible with. This could make our goal of widget serialization a bit trickier to achieve as the typetag crate (necessary for enabling the serialization of trait objects) does not support generic traits. This could possibly be worked around by using a separate trait for widget serialization, e.g. SerdeWidget, that is only implemented for widget implementations over some dynamic data representation.

Unfortunately, we can't try using druid directly in a nannou app for a couple of reasons:

  1. druid rolls its own shell (windowing library) from scratch. This means we can't just convert winit events into some druid input event type to drive it forward - druid itself requires managing windowing, events etc. This makes it impossible to run alongside nannou, as both require ownership over the main event loop, of which there can only be one, particularly as the event loop requires running on the main thread on some platforms.
  2. druid requires using the piet 2d rendering library for rendering its graphics. piet does support multiple backends, but no wgpu backend just yet. I imagine even if piet does land wgpu support, it might be confusing to users to have to switch between entirely different renderers going between the draw and ui APIs.

We would also begin to run into some of the same issues as we currently have with conrod where users cannot use nannou positioning and colour types direclty in the UI API or vice versa, requiring a conversion step between the two which is frequently confusing for new users.

Manual Synchronisation ("classic" retained GUI)

On the opposite end of the spectrum, we could opt for a more classic retained approach, where the GUI remains entirely separate from the application state and does not require a reference to it during rendering. In these designs, updating the application state can be achieved by either callbacks, channels or matching on widget IDs alongside their associated events. Synchronising GUI state can be achieved by manually indexing into the gui with widget IDs and updating state as necessary.

The tedium of the manual approach is often related to the separation of all of the steps at which synchronisation is necessary. E.g.

  1. On intialisation, the GUI should be initialised with state that reflects the application.
  2. On user input, windowing and application events, GUI interaction should be able to update application state.
  3. When application state is updated via other means (e.g. I/O, OSC, audio/video, controller, etc), the GUI must be updated to match.

Conrod's immediate design consolidates all of these steps into a single step using caching to hide the distinction between initialisation and repeated updates. Druid's data-driven design is similar, with the slight difference that steps 2 and 3 are split into two methods. While these two libraries provide arguably simpler APIs, both do so at some other cost (performance in the case of conrod, strict Data and Clone requirements on application state for druid).

The major benefits of the manual synchronisation approach seem to be performance and API flexibility. No work is performed except when absolutely necessary, and no restrictive trait implementations or design constraints are required to achieve this. It should also be easy enough to build an immediate or data-driven API on top of a more classical retained API, whereas it would make less sense to do the reverse due to the performance cost that has already been paid for the immediate design, or the state restrictions that are already imposed in the data-driven design.

That said, another issue with the classic retained approach is that widgets need to independently store all necessary state for rendering and handling events. E.g. in order for a list to present unique text for each button, it must store its own container with a String for each element. On the other hand, a data-driven design has the benefit of referencing that data directly from the application state during rendering or event handling. That said, the data-driven approach needs two copies of the whole application state when updating widgets anyway, so it could be argued that it's not necessarily more memory efficient unless taking care to structure application state with immutable data structures. Then again, immutable data structures are renown for making it easy to cause unintended leaks in other ways due to the amount of reference counting required.

To be continued...

mitchmindtree

comment created time in 8 days

pull request commentRustAudio/cpal

Prototyping an API for getting the supported min and max buffersizes

@Ralith good point! Surely there's a reliable way to check availability of IAudioClient3, or even just check the Windows version. I'll look into this tomorrow with @JoshuaBatty.

JoshuaBatty

comment created time in 8 days

issue closednannou-org/nannou

distance between points

in p5js there's a dist function to get the distance between 2 points. https://p5js.org/reference/#/p5/dist

There's an equivalent in nannou? I was not able to find it in the documentation. Even if it's a simple thing is very used in p5js projects so would make sense add it as an util

closed time in 8 days

milonite

issue commentnannou-org/nannou

distance between points

Closing this now, though feel free to re-open if you're still unsure how to use the advice shared above.

milonite

comment created time in 8 days

issue closednannou-org/nannou

Abstract laser `Frame` and related optimisations from `nannou_laser` into a separate crate

This would allow folks to use the Frame streaming logic and optimisations in their own laser API implementations.

nannou_laser would then include this crate as one of its dependencies.

closed time in 8 days

mitchmindtree

issue closednannou-org/nannou

Add ability to toggle euler graph draw order optimisation pass

Currently the draw order optimisations are always applied, however in some cases it may be desirable to retain the original, non-optimal path in order to ensure symmetry in the resulting path distortions.

Often optimal paths are unintuitive and asymmetrical. This means that, while the projector has a chance of drawing the image more accurately, it can also result in asymmetry in the case that inertia-related distortions do appear.

This may require updating the interpolation process in the lasy crate in order to be a bit more flexible and support interpolating non-euler-circuit point sources.

closed time in 8 days

mitchmindtree

issue commentnannou-org/nannou

Add ability to toggle euler graph draw order optimisation pass

Closed via #610.

mitchmindtree

comment created time in 8 days

issue closednannou-org/nannou

Add the ability to bypass LASER frame path optimisations

This would be useful for seeing the effect of each optimisation on the resulting frame and how much pathing is improved by applying each one.

Perhaps the set of active passes could be described using bitflags.

closed time in 8 days

mitchmindtree

issue commentnannou-org/nannou

Add the ability to bypass LASER frame path optimisations

Closed via #610

mitchmindtree

comment created time in 8 days

issue openedRustAudio/cpal

Is there still a use-case for the emscripten host (`wasm32-unknown-emscripten` target)?

Forgive my lack of web target experience! I'm just wondering if there's still a motivating use-case for the wasm32-unknown-emscripten backend that would not be covered by the webaudio target (wasm32-unknown-unknown)? Could any folks more familiar with the web targets weigh in on this, and perhaps discuss where use-cases might differ between the two?

created time in 8 days

delete branch mitchmindtree/cpal

delete branch : webaudio-poc-rebased

delete time in 8 days

pull request commentRustAudio/cpal

Prototyping an API for getting the supported min and max buffersizes

Seeing as it looks like the only way to reliably get the min and max buffer size via WASAPI requires Windows 10, I think it makes sense to have WASAPI just return both the min and max as whatever the default buffer size is by default so that users of WASAPI on older versions of Windows can at least use CPAL at all, even if they can't configure the buffer size.

Perhaps having some way of allowing users to opt-in to using the Windows-10-only IAudioClient3 is the way to go? Originally I mentioned the idea of using a feature flag to @JoshuaBatty, but after thinking a little further on it, perhaps it's better to have a WasapiHost-specific, alternative device constructor that constructs the device with IAudioClient3 rather than IAudioClient? E.g. something along these lines:

let (host, device) = if cfg!(target_os = "windows") {
    let wasapi_host = cpal::WasapiHost::new().unwrap();
    let wasapi_device = wasapi_host.default_output_device_iaudioclient3().unwrap();
    (wasapi_host.into(), wasapi_device.into())
} else {
    let host = cpal::default_host();
    let device = host.default_output_device().unwrap();
    (host, device)
};

// Enumerate supported configs, create streams, etc...

Thoughts?

Also, perhaps it might even be worth leaving this opt-in-windows-10-API stuff for a separate future PR and just focusing on landing the default case for now?

JoshuaBatty

comment created time in 8 days

issue openedRustAudio/cpal

Add support for input streams to webaudio host

Currently the implementation panics with unimplemented!().

created time in 8 days

issue openedRustAudio/cpal

Provide proper range of available channels in webaudio backend

Currently two channels is hard-coded throughout the implementation. However, an inline comment mentions that browsers must support between 1 and 32 channels. We should investigate and see if there's an API for acquiring the number of channels available on the device targeted by the browser, as e.g. there's no point allowing the selection of 32 channels if only two are available.

created time in 8 days

issue openedRustAudio/cpal

Provide proper range of available sample rates in webaudio backend

Currently 44.1khz is hard-coded throughout the implementation. However, an inline comment mentions that browsers must support all sample rates from 8khz to 96khz.

created time in 8 days

issue openedRustAudio/cpal

Address arbitrary stream delays introduced in webaudio host

Currently there are two places where an arbitrary delay is used to avoid buffer underruns in the webaudio host.

  1. On Device::build_output_stream_raw the first emitted buffer is delayed by 25ms.
  2. On Stream::play a 10ms delay is introduced. @dpeckett just to clarify, this was to avoid a buffer underrun you were running into yes? Or was there another reason for this one?

It would be worth investigating to see if there's an alternative solution to avoiding early underruns.

created time in 8 days

PR closed RustAudio/cpal

Add a wasm-bindgen based generic WebAudio backend.

Add a generic wasm-bindgen based WebAudio backend. Uses a sample scheduling strategy based on a set of interleaved AudioBufferSourceNode's which are rotated in and out as they finish playback. A quick port of the beep example appears to play stutter free on Firefox and Chrome.

+447 -1

22 comments

5 changed files

dpeckett

pr closed time in 8 days

more