Input for seconds for "osctime" (?and note block?)

[sugarlabs]

Input for seconds for "osctime" (?and note block?)

[walterbender]

Why mix units?
On Oct 13, 2015 11:34 PM, "Devin Ulibarri" [email protected] wrote:

Okay, the logic for the Hz blocks is much better, but I thought that
"osctime" block would take input in seconds (and that would be its defining
characteristic). Currently, it behaves just like the "note" block.

We need to either:

1. Keep "osctime" to a milliseconds only (for input argument) block
2. Allow for both "note value" and " duration in milliseconds" input to
   "osctime"
3. If 2, then possibly introduce this to our note block as well.

My gut feeling is just do 1 from this list, but have it take "pitch"
blocks as potential arguments (and visa versa).

—
Reply to this email directly or view it on GitHub
https://github.com/walterbender/musicblocks/issues/40.

[pikurasa]

@walterbender Are you asking, "why mix them in general" or "why mix them into a single block as input"?

Answer to latter is, I do not think this is necessary, that is why I would prefer solution 1 above.

Answer to former is, "well, if we are introducing the level of control of 'pitch in hz', why not do 'rhythm as milliseconds'?" I thought it would be easy enough to implement (we seemed to have it before) and it would definitely be a fun intersection of math and music.

This reminds me, I wrote a piece involving oobleck, a bass speaker, and some sounds I created with Audacity that I composed entirely in Hz and seconds.
Check it out here https://www.youtube.com/watch?v=MjqR5TfTNGI

Are you convinced yet?

[walterbender]

Here is my issue: how do we make it clear to the user that they are
inputting one or the other. At first I thought we could do it by range. 64
or less would be a note duration and > 64 would be HZ. But that is not very
robust. Maybe we can introduce a new datatype for note duration like I did
for pitch types, but it gets a bit tricky when we use operators on those
types. I will have to think about it. In the meanwhile, I think it makes
sense to use the same mechanism for osctime as notes. In fact, maybe that
is the solution: why not interchange the synthesizer blocks with pitch and
have either note or osctime, the difference being duration vs milleseconds.
So you could use a pitch block in an osctime clamp and a square block
inside a note clamp? Would make my life easier and I think it would be more
straight-forward from the UX perspective. Your thoughts?

On Tue, Oct 13, 2015 at 11:46 PM, Devin Ulibarri [email protected]
wrote:

@walterbender https://github.com/walterbender Are you asking, "why mix
them in general" or "why mix them into a single block as input"?

Answer to latter is, I do not think this is necessary, that is why I would
prefer solution 1 above.

Answer to former is, "well, if we are introducing the level of control of
'pitch in hz', why not do 'rhythm as milliseconds'?" I thought it would be
easy enough to implement (we seemed to have it before) and it would
definitely be a fun intersection of math and music.

This reminds me, I wrote a piece involving oobleck, a bass speaker, and
some sounds I created with Audacity that I composed entirely in Hz and
seconds.
Check it out here https://www.youtube.com/watch?v=MjqR5TfTNGI

Are you convinced yet?

—
Reply to this email directly or view it on GitHub
https://github.com/walterbender/musicblocks/issues/40#issuecomment-147924562
.

Walter Bender
Sugar Labs
http://www.sugarlabs.org

[pikurasa]

In fact, maybe that is the solution: why not interchange the synthesizer blocks with pitch and have either note or osctime, the difference being duration vs milleseconds. So you could use a pitch block in an osctime clamp and a square block inside a note clamp? Would make my life easier and I think it would be more straight-forward from the UX perspective. Your thoughts?

I must have caused confusion with my clumsy title to this issue. If I understand you correctly, I agree this would be best (and what I am trying to express in solution 1 above).

I think this is the solution, but I will entertain the other ideas below:

Here is my issue: how do we make it clear to the user that they are inputting one or the other. At first I thought we could do it by range. 64 or less would be a note duration and (greater than) 64 would be HZ. But that is not very robust.

I agree that this would not be good.

Maybe we can introduce a new datatype for note duration like I did for pitch types, but it gets a bit tricky when we use operators on those types. I will have to think about it.

Yes, we want to easily be able to use other operators on our note values.

[walterbender]

I implemented osctime to behave just like the note block, only it uses MS instead of beat values. Both blocks can play osc or pitch blocks.

[pikurasa]

Brilliant!

Resolved.