Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

beta 1.3

13567

Comments

  • SimeonSimeon Admin Mod
    edited January 2012 Posts: 5,708

    @Fred - does this sound picker always crash? I think I found a bug with pressing the previous button on the waveform type. My stupid assumption that the C mod operator behaved the same as Lua's for negative numbers.

    @Bortels @ruilov thanks for the feedback re IAP. We'll always provide great new features for free (such as the basic sound picker, which I think is more useful for 90% of people). The extra stuff is there for people who really want it, or want to support us. We will never sell anything that causes fragmentation – so the sound() API is still full featured, but the convenience of complex sound editing within the code editor is an extra. You could still write your own "Spritely" equivalent for sounds with the base package, as @Fred mentioned.

    @Andrew_Stacey I touched on that in the release notes. We will have an API to startVideoCapture and stopVideoCapture. It will be in soon. I am thinking stopVideoCapture will always bring up an alert or operating-system level message of some kind informing you that a video has just been saved to your camera roll. Also there will be some indicators that video recording is taking place (such as a red border) that aren't recorded.

    @Bortels the editor is far too slow to record with the OpenGL view. It's unfortunate because it would be nice. Edit: also we will have a function to disable the watermark. It will be on by default, though.

  • BortelsBortels Mod
    Posts: 1,557

    Ah - pity. I understand, but pity.

  • JohnJohn Admin Mod
    Posts: 643

    Recording the entire app is another kettle of fish all together. I use some very specific tricks and optimisations that make recording the opengl context fast (even on ipad 1 surprisingly). Recording the side bar and the editor goes way beyond that scope. That being said, i've seen fullscreen recordings that use a jail broken ipad, so that might be your best bet for now.

  • BortelsBortels Mod
    Posts: 1,557

    Hmm. I have a jailbroken ipad. I wonder what they used. Will google.

  • SimeonSimeon Admin Mod
    Posts: 5,708

    @frosty did a Codea overview and used a screen recorder. The result is here: http://frosty.tumblr.com/post/11687070069/codify – I forgot the name of the app he used.

  • Posts: 447

    the sound picker crashes the app for me. I type sound() in a project, then click between the () and then codea crashes

  • BortelsBortels Mod
    Posts: 1,557

    So - just to point it out if it's not already obvious - apparently if you search the conversations of specific users, all results come up - inclusive of the beta forum. You CANNOT trust coders, we are a slippery bunch. The information here is public knowledge, or will be shortly.

  • SimeonSimeon Admin Mod
    Posts: 5,708

    @ruilov ah that's an oversight. I forgot to test no parameters after adding the advanced picker. If you type sound(SOUND_BLIT, 1234) then tap that, it should work.

    @Bortels good to know. It's not so much that we're trying to keep secrets, I just don't want beta discussion cluttering up the normal help, questions and sharing that goes on in the forums. Especially when it comes to API changes - people may think they have access to something that is not released yet and get frustrated.

  • BortelsBortels Mod
    Posts: 1,557

    Yep, that's what I figured. You have a VERY inquisitive userbase. That's good, I think.

  • Posts: 447

    @Simon got it, it's nice!

    On the rec button, in 15 mins I already pressed it 3x trying to press reset. I think it's fine where it is but will take some getting used to

  • SimeonSimeon Admin Mod
    Posts: 5,708

    @ruilov it will be moved. That whole bar is getting a re-thought and re-designed.

  • Posts: 384

    @Simeon, yes when empty the advanced sound picker crashes, but your workaround brings it up.

    It's very good, I like how it plays the sound when you lift your finger from the sliders. I would suggest using bigger slider buttons in terms of knowing when you are touching it, but having more visibility of how far you have moved the slider. Seem of these sounds need very fine adjustment, and I can't see it under my finger. Perhaps something with a sharp end like on a radio tuner?

    I also think the advanced one should let you record exactly which values you are using, rather than only the compressed data. That will help people fine tune a sound and then modify it programmatically.

    For the basic sound picker, it does show the random seed values, but it could take a while to find the one you want. What if you implemented spinnies on that?

  • BortelsBortels Mod
    Posts: 1,557

    Re. Finger over the slider - I have the same issue, but it's easy to work around.

    Press and hold on the slider knob, then slide your finger perpendicular to the slider - in the case of the sound picker, slide down. You'll still be "holding" the slider - but now you can see it.

  • SimeonSimeon Admin Mod
    Posts: 5,708

    @Fred thanks for the feedback! With the basic picker, the random seed is basically meaningless (except as a way to recreate that exact sound). Does going through them faster or slower really help?

  • Posts: 2,161

    Been playing with fonts a little. The width and height work well for putting text blocks together, but I do find that I want a little finer information from time to time, namely the actual height and depth of a piece of text. This is for placing sub and superscripts correctly. For example, if you measure the height of "a", "k", and "y" then they are all the same, but sub and superscripts would be positioned slightly differently on each.

    Also, the clipping is a little too tight on italic text. Try a word ending in "f" with Hoeffler-Italic.

    Another thing. I find that if I import a file using direct filesystem access then I also need to add it to Info.plist, otherwise Codea deletes it (files ending in .lua, that is). This is annoying! Okay, it's not hard to remember, but even so ...

  • SimeonSimeon Admin Mod
    Posts: 5,708

    How are you implementing direct filesystem access?

  • Posts: 447

    I was bitten by this too Andrew. Simon, if you use iexplorer or something like that to move lua files in or out. If they're not in info.plist, codea will not display them and it will delete them.

    I would have expected to insert them as tabs at the start or end

  • SimeonSimeon Admin Mod
    Posts: 5,708

    Hmm. This is because the Info.plist defines the project. For example, when you delete a tab, Codea simply removes it from the Info.plist. The project saving mechanism uses that to determine whether to remove the file from the filesystem on the next save operation.

    I'll make future beta versions not do this. That is, they'll keep everything, even if you delete a tab from the project it will still sit in the filesystem. I'm not sure what sorts of bugs this will cause, but that's what you guys will tell me :)

  • BortelsBortels Mod
    Posts: 1,557

    I suspect you'll find, especially with .codea access gone, that many or most of your users are doing direct access of some flavor or another.

    I'd suggest you delete a lua file when someone deletes the associated tab; any other cleanup shouldn't be your responsibility, you didn't put the file there. If they kill the project, zap the whole directory.

    Is there a way to notify codea of changes, other than bouncing it? I wonder how iTunes file sharing coordinates things (if it even does)...

  • Posts: 384

    @Simeon, although the seeds are arbitrary, they are persistent. Whenever you open up the picker it shows the last one you used. I wouldn't want to always come back to the same value and have to spend time flipping through the same sounds over and over again when looking for a suitable one. Having a way to rapidly scroll through the seeds, or a randomise button on the basic picker would solve this.

  • Posts: 384

    @Bortels, thanks for the tip on moving the fat fingers off the slider to see it... :)

    I still feel that more precision is needed in representing what value we are setting. Some of the sound parameters need to be set exactly half-way in the middle to achieve a balance between sliding a note up or sound, for example. You can't really tell without a thin pointer on the handle and center notches next to it.

    @Simeon, how about widening the advanced sound picker to make it easier to adjust with small finger movements? I think you could make it twice as wide - it doesn't bother me covering up the code window, as we are engrossed in choosing sounds.

  • SimeonSimeon Admin Mod
    edited January 2012 Posts: 5,708

    @Fred: Good points. On the basic I could make it jump to a random seed when you press back and next, or I could bring the "Randomize" button in from the advanced panel so that you can randomise all the seeds.

    I've just sent out a beta 1.3 (8) so I didn't get to widen the sound picker, but I'll do that in the next build. Note that there are only 255 discrete values for each sound parameter due to the encoding.

    While the advanced sound picker will never be able to write out a table into your code, we will add a function to turn the encoded sound into a table so you can programatically adjust it. (Maybe soundTable( "encoded string") or just have sound() return the table directly.)

  • SimeonSimeon Admin Mod
    edited January 2012 Posts: 5,708

    Also this beta should stop trashing your extra files - it may not load them, but at least it won't delete them. Forgot to put it in the release notes.

    Edit: also forgot to mention that parameter sliders now move when the variables they are tracking are changed programmatically.

  • BortelsBortels Mod
    Posts: 1,557

    Hmm - maybe put a numeric field next to the slider, for fine-tuning?

  • Posts: 384

    @Simeon, I reckon putting a randomise button on the basic sound picker would be best. This lets people find their way back to their favourite seeded sound.

    I like mySoundTable = sound(xhejehsgebetcetcetcetc) and maybe you could reverse it to let users convert a table into an encoded string with myEncodedSoundString = sound({StartingFrequency = 42, etc}) ? :). Then sharing a cool sound would be easy...

    Doubling the pixels would still help fine selection, even though you are not encoding more than 255 possibilities.

  • Posts: 384

    Good thinking @Bortels ! A little number would be best. Would that use a percent or the actual value that matches the programmatic interface? That could be helpful.

  • Posts: 2,161

    I'm having some fun with the font stuff and the keyboard. It's a bit annoying that the keyboard covers the buttons - one can't start with the keyboard in place and record stuff, for example.

    I'm also getting some missing characters in the keyboard buffer. Most particularly spaces after or before punctuation. I'm not totally sure of the exact conditions but they seem pretty consistent: when I type hello *world* then the space after hello disappears.

    I worry a bit with the font stuff that the issue with string manipulation might bite. I want to do something where I can have line wrapping but can change the font (for example, typeset a word in bold). This means that I can't use the textWidth feature but have to measure stuff myself and figure out if I need to break the next piece or not. As the fonts tend not to be fixed width, I can't just figure out where to break it but have to do a bit of guesswork. Each guess will involve splitting a string, thus creating new ones. So I'm worried about hitting the instruction limit - as I did with my utf8 stuff (which I've now fixed). Any ideas, or am I just worrying over nothing?

  • BortelsBortels Mod
    Posts: 1,557

    Keyboard? Keyboard? (runs codea...) Holy Moly!

    If we can accept keyboard input without the keyboard up (ie. via bluetooth), I'll kiss a moose. No, really. I'll do it. Just sayin.

  • SimeonSimeon Admin Mod
    Posts: 5,708

    @Andrew_Stacey: very interesting "helloworld" bug. If you respond to the keyboard(key) function instead you'll notice it delivers a space at the appropriate time.

    I only added keyboardBuffer() as a convenient way to access the data, but if it's flaky it might have to go.

    Also, how should we handle backspace? At the moment an empty key ("") is delivered to keyboard(key). Other solutions would be appreciated.

  • BortelsBortels Mod
    Posts: 1,557

    NOW I HAVE TO FIND A MOOSE!

    You can add "iCade support" to your list - just tested, works fine.

    I need to see about wrapping it up in an easy-to-use class (it shows up as keystrokes, which is just fine). Maybe see about adding it to Nat's controllers (I'll make a tab that can drop into his existing project).

  • SimeonSimeon Admin Mod
    edited January 2012 Posts: 5,708

    @Bortels that should work, I haven't tried it because I don't have one on hand. Perhaps you could try and let me know if there are any issues? You may need to show it, still, just to enable focus to the hidden text view.

    Edit: That was fast!

    Edit2: Suggestions for the API would be great

    Edit3: There's a problem trying to do this keyboard API in the conventional (i.e., PC) way. The main one is that there are no special keys, such as backspace, arrow keys and so on. The only information iOS provides when data is changed in a textfield is to replace characters in range [X, Y] with string S. I'd still like the API to be somewhat cross-platform in its idiom.

  • BortelsBortels Mod
    Posts: 1,557

    backspace should send the ASCII backspace code (decimal 8) as key, shouldn't it? Likewise, how do you handle "return", or the arrow keys? Anyone reading input raw with keyboard(key) should be able to handle those sorts of things.

    Hmm - what about modifiers - Control-C? perhaps key should be a keycode and not a character.

  • BortelsBortels Mod
    Posts: 1,557

    If you do showkeyboard() with the bluetooth keyboard enabled, no keyboard shows, but the bluetooth keyboard is enabled. This matches the behavior on the rest of the ipad, so that's perfect.

  • BortelsBortels Mod
    Posts: 1,557

    PS. it was fast because I have my icade at work. now I have to bring it home with me! (yes that's backwards.)

  • SimeonSimeon Admin Mod
    Posts: 5,708

    Like I said above, there's no way to get modifiers - which is really unfortunate.

    The only way to get arrow keys, for example, is to see if the selection area changes in the hidden text field. However that breaks when the selection caret can't move (at an edge).

    Backspace is delivered to me as: "replace this range (potentially multiple characters) with the empty string." I don't want to be too quirky and just give that information to the user, because if Codea is ported to a desktop platform it becomes some weird iOS-ism. At the moment you have to check for "".

  • BortelsBortels Mod
    edited January 2012 Posts: 1,557

    Blearrrgh. Ok... since each key event it seperate (right?) can you pass "backspace" and "return" and so on? I mean, as strings?

    There's GOT to be a way to read raw keycodes. How weird.

    By the way - I am TOTALLY JAZZED about this. I've wanted to write for the iCade since Day 1.

  • Posts: 2,161

    I was just coming to report that the issue seemed to be with the buffer, not the actual input, but you beat me to it.

  • BortelsBortels Mod
    Posts: 1,557

    re. the keyboard - is there any chance we can get a function to tell if the bluetooth keyboard is present?

    see http://stackoverflow.com/questions/2893267/ipad-detect-if-external-keyboard-is-present

    Here's the scenario - I'm a game, wanting joystick input. If I detect bluetooth, I'll use iCade controls - but if not, I'd like to default to a virtual joystick from Nat's controllers library. It would be slick if I could just tell.

    It's not a giant thing - I could simply have a modal "choose your controls" dialog box when the project starts. But - it could be handy.

  • SimeonSimeon Admin Mod
    Posts: 5,708

    @Bortels return should come up as "\n"

  • SimeonSimeon Admin Mod
    Posts: 5,708

    @Bortels I was thinking of passing keyboardWillShow / Hide callbacks on. And that seems to be the only way to detect an external keyboard without using private APIs.

    However iCade support is done differently, it's something we might add native support for in the future. With iCade support the software keyboard would not be involved at all.

  • Posts: 447

    @Simon

    • First thing I did was throwing a showKeyboard() inside draw() and then I was stuck. Had to restart codea to get out. I'm sure you're on it but I might as well report

    • Re the API I'm confused. You get a "replace this range with empty"? What range? That would make sense if the keyboard was associated with a text field/string, but it's not it's just a keyboard. There's no string for the "range" to refer to. Or did I miss something?

    • text box. A very basic text box would go very well with the keyboard API. If you don't offer it, a lot of people will write their textbox version, which is ok too, but would be nice to offer a simple one.

  • BortelsBortels Mod
    Posts: 1,557

    ??? Color me confused - the icade I have here sends keystrokes, I tried it! It looks like a Bluetooth keyboard, so when it's paired and you do showkeyboard() no keyboard shows up - but that's the desired behavior.

    If I do showkeyboard() and there is no keyboard event - that says I have Bluetooth and can assume icade. Problem is, if not - I get a keyboard I didn't want. Hmm... May be better simply to prompt for a controller type...

  • SimeonSimeon Admin Mod
    Posts: 5,708

    @ruilov good point about sticking showKeyboard() in draw. The keyboard is actually associated with a hidden text field. I get information about the range, I was wondering if I should pass that on. Regarding the text box: we probably won't include one in this update, there is too much other stuff to add.

    @Bortels yeah the problem is there is no way in iOS to detect if there's an actual hardware keyboard present. However I might look at adding a showKeyboard(HARDWARE_ONLY) mode to the function. This will do the same thing except disable the software keyboard.

  • BortelsBortels Mod
    Posts: 1,557

    That sounds like it would work fine.

    By the way - I probably don't have to say this, but I'll say it anyway - this update is awesome. I'm basically picking nits, trying to give the best beta feedback I can, but know that underneath it all what you have here is really solid - I have to look, hard, for anything to suggest - you could ship it as is and they'll sing your praises, and I'd be right there with them.

  • SimeonSimeon Admin Mod
    Posts: 5,708

    Thanks @Bortels

    @Andrew I fixed the "hello world" bug. Oddly it depended on the size of the hidden text field. It seems that some words lined right up to the edge, were wrapped by iOS, and not spaced in the buffer. Bizarre. It would do it for words like "hello", "jello", but not "ello" or "hellow." I've changed the size and it appears to be fixed.

  • Posts: 384

    @Simeon, the Advanced sound picker width is good now. A little value readout on every slider would be grand, so you can set it right in the middle, or take note of the value.

    Would it also be possible to trigger the sound from the play button while the slider is being held? I was intuitively trying to do that with two hands to audition differences on a slider, but you currently have to lift your finger. Unfortunately that means grabbing and releasing the slider a lot which can get tedious.

    I echo @Bortels' comment - this is a smashing update. I love the physics examples, and my toddler thought it was hilarious to fling the little trolley into space in the last one! :)

    In terms of the IAP, it would be interesting to test out your market to see how that goes. I hope there is a way you can sustain development of this platform, and if that's the way then go for it!

  • Posts: 384

    @Simeon, there's some kind of bug with the latest build when I try the Sounds Plus example. It relates to the parameters in setup. It seems if there are too many of them it freezes Codea after setup().

  • Posts: 2,161

    Great on the "hello world" bug! And ditto on the general praise .. the stuff here is fantastic and I've only been playing with fonts and recording!

    I'm trying to work out the best way to work with text input/output. If I have a fair amount of preprocessing to do, so it's not a simple "get string, print string" then is it okay to work with strings, or should I split everything into a table as early as possible? Working with the keyboard function (rather than the buffer), then everything comes in key by key so it seems natural to work with tables, but somehow strings are easier to code for. Any advice?

  • BortelsBortels Mod
    Posts: 1,557

    My take is that as long as the strings aren't large (for some very fuzzy definition of large), you're fine with strings. I'd say start with strings, but keep in mind you may need to break it out to tables for performance at some point. Also keep in mind the worst-case scenario for strings is appending a single character, which basically makes two copies of the whole thing (and may be just what you're doing in an input routine), and adjust accordingly.

  • Posts: 2,161

    Was the hello world bug meant to be fixed in the latest update? If so, it doesn't seem to have worked. I still don't get a space after hello.

    Bortels, yes but I'd like to know what the "fuzzy definition of large" is! I ran into problems with a simple word-wrapping routine on strings that I wouldn't consider long (don't remember off-hand, but it was only a couple of sentences). So that suggests using tables the whole way. There are only two issues with that:

    1. Using tables the whole way would mean putting stuff on the screen character by character. I presume that it is more efficient to say text("abcdefg",x,y) than for k,v in ipairs(chars) do w,_ = textsize(v) text(v,x,y) x = x + w end, but how much more efficient?
    2. I've slurped some code off the internet (you might be able to guess what by thinking about what my input above was: hello *world*) which uses strings. I could recode it to use tables, but it would be nice to know if the pain would be worth the gain.
Sign In or Register to comment.