Comments (3)
Excellent! Thanks!
from wavefile.
Hey @kylekyle, thanks for the feedback!
I think the original reason I made each_buffer
close the file was so that you could read an entire file by doing this:
Reader.new("my_file.wav").each_buffer do |buffer|
# Do something with buffer
end
If it didn't automatically close the file, you would have to do this instead:
Reader.new("my_file.wav") do |reader|
reader.each_buffer do |buffer|
# Do something with buffer
end
end
Or this:
reader = Reader.new("my_file.wav")
reader.each_buffer do |buffer|
# Do something with buffer
end
reader.close
(Both examples currently don't work, as you pointed out).
It's possible that optimizing for succinctness here is the wrong trade-off, because it reduces the flexibility to use each_buffer
in different ways, and it could also be confusing. To be honest it's not something I've thought about for awhile, but as I look at it now the current interface does look a little weird to me.
I see a couple of options:
- Change
Reader.close
to no longer raise an error if theReader
is already closed, as you pointed out. - Change
each_buffer
to no longer close the file when the block exits, as you pointed out. - Add a new way of opening a file for buffered reading. E.g. something like:
WaveFile::Reader.read_buffered("my_file.wav", <optional buffer size>) do |buffer| # Do something with buffer end
1.) Seems like the most appealing option. I originally made Reader.close
raise an error if the file is already closed to match the behavior of IO.close
. However, it looks like IO.close
no longer raises an error as of Ruby 2.3, and I'm not sure of another reason why this should raise an error in that scenario. It seems like changing this behavior would allow the examples you gave to work.
I'm wary of changing each_buffer
to no longer close the file because it would cause unexpected behavior in existing code that uses the Reader.new.each_block {}
pattern - if you updated the gem without changing you code, your code would silently change to leave the file open forever. I'd have to think more about the trade-off between a potentially better interface vs. breaking existing code.
I'd have to think more about 3.)
Finally, is there a specific use case that you aren't able to do based on the current behavior? I.e., one work-around would be to use the Reader.new.each_buffer {}
pattern, unless what you are trying to do isn't possible with that.
from wavefile.
Hey @kylekyle, I released v1.0.0 of the gem a few days ago, and as of that release Reader.close
and Writer.close
no longer raise an error if the Reader
/Writer
is already closed. I think that should allow the code in your examples to work.
I’ll keep in mind the other suggestions you made as possible changes for the future, but I’m not planning to make any immediate changes.
Thanks for raising this issue!
from wavefile.
Related Issues (20)
- Possible bug when no block is given to the writer? HOT 2
- No high-level duration info HOT 2
- Example here - https://github.com/jstrait/wavefile/wiki/WaveFile-Tutorial#copying-a-wave-file-to-different-format working correctly? HOT 5
- fyi: ruby-wavefile now packaged for Debian HOT 1
- support reading from a file or stream HOT 5
- Duration does not override equality HOT 2
- UnsupportedFormatError HOT 8
- Method to obtain markers/cue points HOT 6
- Reference for older methods HOT 4
- examples: how create reverse file? HOT 2
- Mix 2 wav files. HOT 2
- Rewind the IO object HOT 4
- Format Chunks With Extra Bytes at the End Sometimes Cause `InvalidFormatError` to be Raised HOT 1
- `Reader` instances can be created for WAVE_FORMAT_EXTENSIBLE files that have an incomplete/missing format chunk extension HOT 1
- Bufer from bytes & mulaw HOT 2
- WaveFile::Reader doesn't work with pipe IO HOT 2
- Sample Data Can't Be Read From a WAVE_FORMAT_EXTENSIBLE File With an Oversized Format Chunk Extension HOT 1
- How i can play file HOT 1
- Misleading error message if "fmt " chunk extension is too large to fit into chunk HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from wavefile.