Snapinator development (Snap! programmers wanted)

For those who aren't familiar, Snapinator is a web app that allows you to open Scratch projects in Snap!

It's been about 6 years since the first version, and there are still quite a few blocks that Snapinator doesn't support. In the past, there was no way to replicate many of these features in Snap! except with the JS function block, and I was hesitant to do this.

By now, Snap! has grown into a much more capable language. New, exciting features like media computation should make it possible to reimplement almost all of the core Scratch features (which don't require external devices) in Snap! itself. I want to finally bring Snapinator to feature completion by writing these missing features, and I'd appreciate some help with this.

These are the "help wanted" features. No JS allowed unless it's used by library blocks. Show off what Snap! can do!

These blocks appear to be easy to implement, but they have quirks that need to be investigated:
[scratchblocks]
when [loudness v] > (10) // Done, thanks spaceelephant!
when video motion > (10) :: pen // Done, thanks spaceelephant!
[/scratchblocks]

These blocks should be possible to implement with Snap! media computation features:
[scratchblocks]
change [pitch v] effect by (10)
set [pitch v] effect to (100)
clear sound effects
play drum [(1) Snare Drum v] for (0.25) beats :: pen
set instrument to [(1) Piano v] :: pen
[/scratchblocks]

These features should be possible with the web services library, media computation, and external services like AWS Polly and Google Translate:
[scratchblocks]
speak [hello] :: pen
set voice to [squeak v] :: pen
set language to [Icelandic v] :: pen
(translate [hello] to [Russian v] :: pen)
[/scratchblocks]

1 Like

When loudness, timer or video motion is greater than a number. This is how the scratch ones work. Because of the block variables, you will have to use a custom block.
untitled script pic
You should use javascript when you need to. Language and username are important features, but they can't be made any other way, and the url block is not powerful enough for the translate blocks. Minimize javascript, but use it when you have to.

List reporter is just join input list.

Very nice, thanks.

Not quite. Depending on the types and lengths of the list items, sometimes it behaves as join, sometimes as join words.

Ok, a bit of JS might be necessary to make POST requests. Everything else should be doable in Snap!

Consider using our existing web services library instead of reinventing it.

Yes, that would make sense.

[scratchblocks]
(username)
[/scratchblocks]

is doable with one line of JavaScript:

return this.parentThatIsA(IDE_Morph).cloud.username;

I think I know how to do pitch effect, but that would mean a new list with all the sounds without effects

Yes, I'm just a bit wary of encouraging people to mess with the Cloud object from JS. I really don't think it should be accessible from the JS function block in the first place lest someone decide to play a cruel prank with it...

Hmm, I really don't think that should be necessary. The original sound data will always be available with
[scratchblocks]
([samples v] of sound [ v] :: sound)
[/scratchblocks]

Something that might be necessary is creating a new block like
[scratchblocks]
play sound [] with effects :: sound
[/scratchblocks]

and Snapinator will just replace the original sound blocks with that one where necessary.

Snap does actually have a primitive "item # of thing in list" block.

In scratch it will be join words unless all of the elements of the list are one-character strings. The problem is, if they are one-digit numbers, it will be join words. However, since nobody uses join words, join would be okay. If you don't want that, try
untitled script pic

Yes, but it didn't at the time I wrote Snapinator.

This is my solution:
stringify list

'JS type of' just returns the value of typeof using the JS function block. For absolutely correct type handling I don't think there's any way around it, but getting rid of it is definitely close enough for most cases.

I don't think there should be a difference between strings and numbers. I think that is a bug in scratch that should not be copied. I also have never seen the list reporter used for anything except join input list in scratch.

Unfortunately replicating Scratch's behavior is the point here. :slight_smile:

I'm planning an optional quirks mode for Snapinator which handles ugly type differences in the odd cases where a project relies on them, so I might only include the type check when that's enabled.

There is the Text-to-Speech library built in Snap!
Untitled script pic

Hey!

I meant in scratch. The only uses I have seen for the list block are to concatenate a list of one character strings.

Ah, right. Personally I think the behavior of (Snap!) JOIN when given non-text inputs is weird and useless; I would have restricted its domain to text (including numbers). But we do it because Scratch does.

@djdolphin The username is available in the Getters and setters library.

1 Like