pouët.net

Also there is this version of the editor that is also xplatform:

https://github.com/emoon/rocket/tree/master/ogl_editor

Yep, emoons editor is really neat :)

Thanks :) Lets try the link again.

https://github.com/emoon/rocket/tree/master/ogl_editor

One thing I support in my editor is groups and track folding which I really missed from the old windows editor (also I use pretty much Mac only at home and using Wine/Parallels becomes old after a while) so I coded my own.

I have never really officially announced it but it works on Mac, Windows and Linux (on Linux SDL is required) and have been used in a bunch of productions.

That's so Janteloven of you :)

Nah, it's lazyness. There's more contributors these days than when I originally wrote the copyright-statement. I don't want to spend time on maintaining these things, so it was easier to just remove them all. The commit history already tracks who wrote what, without any effort ;)

Ah right. That actually makes sense.

Speaking of Rocket ports: I was dissatisfied with how many weird VS project I needed to convert to compile DotRocket, and I didn't like all the compiler/linker warnings, and I didn't like that there wasn't an x64 compatible version, so I decided to port the client/player lib to C# without any dependencies.

So I hereby present: https://github.com/kebby/RocketNet

It should be easier to link, and as a plus it should also work on all Mono platforms if you're so inclined. Tested with the small demo system I'm currently conjuring up, and example code coming up when there's demand.

Biggest disadvantage: As it doesn't link against the original client lib, somebody will have to maintain it in case the feature set or protocol changes. But as this hadn't happened in how many years now that's a rather miniscule point :)

Who's awesome? kebby is awesome! :) Great stuff!

kind of works...

Are the tabs automatically generated from the track name?

gargaj: Yeah. I do want to have manual grouping also, but as a first step this should be better than the mess it quicky became before. "default" contains all tracks, though.

Manual grouping as in by the user or by the coder? (Assuming they're different.) I'm doing a similar thing in my tool but I'm going the DAW-way where you can group anything, even other groups, because I often misjudge which tracks I need to see next to each other when editing :D

Gargaj: The user. My longer term plan is create "filter tabs" that contain tracks matching a prefix or a filter, and also possibly editable sets. But we'll see, some times we find out we don't need the more involved stuff, and I have enough other things to work on ;)

I'll just leave this here...


github - pouet

kusma: which branch is active? I have a minor bug report in master, but you may have already fixed it in one of the other branches ;)

Thread resurrection ftw!

@cxw: Still master. I've been committing to it over the last few days ;)

Feel free to file tickets in the github repo, if that suits you...

Gonna try that editor @TLM, looks great.

Just a little hint for intro coders using usync: Don't you think that you can simply remove the call to floor() in usync_update and replace it with a cast to int. /QIfist is your enemy in this case. You really need to round that float down. Spent hours of debugging this yesterday ^^

xTr1m: I'm a bit surprised why that didn't work... float -> int cast should truncate, which should in turn be the same as floor() for non-negative values... And the position should never be negative...

Doesn't that depend on the rounding mode?

When using crinkler and not linking to the msvcrt, you depend on compiler flags like /QIfist, which implement _ftol as a simple fist asm instruction. The documentation of /QIfist specifically mentions that it might change rounding mode, which it does in my case.
I had to implement my own floor method, it's pretty small when using SSE.

Not according to the C++ spec... [conv.fpint] Section 4.9.1 says "A prvalue of a floating point type can be converted to a prvalue of an integer type. The conversion truncates; that is, the fractional part is discarded. The behavior is undefined if the truncated value cannot be represented in the destination type."

But it seems /QIfist breaks this behavior... So yeah, perhaps it's worth keeping that otherwise pointless floor() call...

(my previous post were meant for Gargaj, if that isn't obvious)

kusma: Precisely, the c++ spec explicitly mentions a truncation of the fractional type. But in order to map that functionality to the x86 architecture, the MS VC++ compiler generates a call to _ftol (or its later, more performant, implementations), which ensures that the CPU flags for the floating point rounding mode is set to round down, prior to converting the float to int. It's the call to _ftol which disturbs intro coding, since its implementation resides in the MSVCRT. I don't want to link the MSVCRT, which then causes an unreferenced external symbol error. That's why I use /QIfist.

And by the way, the implementation of floor() is also in the MSVCRT... :)