Loopy Pro: Create music, your way.
What is Loopy Pro? — Loopy Pro is a powerful, flexible, and intuitive live looper, sampler, clip launcher and DAW for iPhone and iPad. At its core, it allows you to record and layer sounds in real-time to create complex musical arrangements. But it doesn’t stop there—Loopy Pro offers advanced tools to customize your workflow, build dynamic performance setups, and create a seamless connection between instruments, effects, and external gear.
Use it for live looping, sequencing, arranging, mixing, and much more. Whether you're a live performer, a producer, or just experimenting with sound, Loopy Pro helps you take control of your creative process.
Download on the App StoreLoopy Pro is your all-in-one musical toolkit. Try it for free today.
Comments
Re: "world improvement" in @SevenSystem's neck of the woods:
When I imported this Midi file into (newly acquired) Xsequencer 2, it helpfully offered to "Automatically manage tracks", which I gladly accepted.
A little later, this feeling crept up on me that either I was going mad, or that this program has no way of reassigning instruments to tracks! There is a global Midi setting, seemingly for assigning instruments - but this was not effecting at all what I was after...
Turned out that the friendly offer was actually a poison pill that closed off a set of editing choices I can make as a user on the document. (And I would suggest some '...' button to be added on the track menus that offers a choice to: 'Enable instrument assignment' or similar, which can then be used to turn off the poison pill.)
I would submit that this is also an example of unexpected "helpful" as well as frustrating behavior by a computer program. Though, in contradistinction, this one is very much in-your-face observable.
There is a manual, you know. And, there are popups fully explaining each and every option the first time you select them. I don't really see any excuse for being flummoxed ... or at least for complaining about being flummoxed by X2.
By contrast, as an IT professional, I have had to shepherd people through the mess of exporting spreadsheets to csv and text so many times over the years that I can't count them. And I don't recall a single clear description in any help file or manual of the behavior ... not that people would really expect that. And yes, there have been some Big consequences from people not realizing this possibility in my business experience, ranging from chewings out from executives to actual adverse financial audit findings.
sorry. I should mind my own business. But that last comment from @Tim6502 cheesed me off for some reason. I'll shut up now.
No. It's a spreadsheet, not a database. The default should be for spreadsheet users who want numbery accountingy mathy things, not data storage. It'd be fairly easy to argue that dropping leading zeroes is indeed a 'sane default' for most spreadsheet use cases.
I kinda agree with that. But also have seen not one person I can recall that expected that to happen in a spreadsheet export. We're talking 30 years of IT support here. So, I get where @SevenSystems is coming from totally.
I can't even imagine the IT support side of these sorts of automagic transformations. I'm a nerd though. I've been using spreadsheets on and off since DOS 6 and I'll admit that I'm pretty much conditioned to look for this sort of stuff and remember to format my cells intentionally.
For me, if the spreadsheet adjusts the visual formatting of a set of cells, I'd expect the export to have that same adjustment. Spreadsheets are supposed to be wysiwyg.
It's a bummer that spreadsheets have completely taken over as databases for casual users. dbase, FileMaker and the like were a good idea though I reckon they all became too complicated for simple stuff at some point.
Tell your client to use an analog notebook and a pen, it will last forever !
Then go back to X2 code
My new track has so much swing now, discovered also the negative delay to stay in line for some reasons...So happy
@rs2000 @Max23 the data is not so much confidential, as it is critical (for updating a large product database). I don't really care a lot about the confidentiality part. I simply don't think that there's 1000s of employees sitting around all day sniffing randomly through the data of hundreds of millions of Google users. But then, I'm really strange in that regard. Absolutely everyone I know cares a million times more about safety and security than I do. Maybe I'm just irresponsible in general
@syrupcore good point about the database vs. spreadsheet distinction, but tell that to my clients! In fact NONE of my clients use spreadsheets as a spreadsheet, and NONE use a database as a database. They ALL use spreadsheets as databases
So maybe there's some kind of miscommunication between users and product providers there in general.
Sure, I'm not saying anyone automatically does bad things with your data.
It's much more the question if you want to open the doors for such.
Spreadsheets vs databases: The way people use them is understandable. Few data sets start out huge, and most users think that a simple spreadsheet will do the job.
And in many cases it does.
Should it grow very large or the customer wants to do more complex data evaluations, many don't even know what a properly designed database could do for them, so they continue waiting for excel macros to complete and if it takes five minutes, they understand it because naturally, the computer is at hard work for such a difficult task
There's a reason why databases are not used as often as they could be.
Try to explain a typical database model to a typical Excel user and you will see his eyes rolling.
I recently had a client who insisted on having data from an intricately linked relational database provided in spreadsheet form, and he could not get his head around the amount of functionality that he would lose and how much bigger the spreadsheet would have to be in comparison to the database because he basically just didn’t know what a database was and wasn’t really interested in knowing. He knows how to use Excel and doesn’t want to spend time learning another thing.
It isn’t microsoft’s fault that he thinks a spreadsheet is a substitute for a database any more than it is a wrench manufacturer’s fault that I don’t know when it makes a difference to use a pipe wrench instead of a standard adjustable wrench.
Where Goggle Sheets is concerned, the subject line strikes me as overly dramatic. This case is not a case if some general unreliability. It is a case of a specific feature that is relevant to a small subset of users AND no original data is lost (i.e. @SevenSystems : you’ve still got the file you imported). Sheets is a pretty amazingly useful FREE service. It is a user’s responsibility to double-check their data (with any app) after importing it. Nothing about this case strikes me as something that merits a dire warning.
@espiegel123 OK, will adapt the topic title to be slightly less dramatic.
Though regarding your comment about "double-checking the data": That is very difficult to do in practice. If you have thousands of rows with dozens of columns (as in my case), and only VERY FEW item IDs actually start with a zero, then it's very difficult to find this "by accident" (double-checking). You would have to KNOW that you have item IDs that start with a zero AND that the importer in Sheets cannot correctly import these*. Fortunately I now know the latter at least, so I can put a yellow sticky note on my monitor
for next time.
ASTERISK yes I know, you will say that it does import them correctly, only that it doesn't work the way I expect. But... yeah
@SevenSystems : to be clear, I agree that it is an annoying behavior/default. I just think it isn't super outrageous and falls within the purview of gotchas consultants need to know about tools they are using.
20+ years of history suggests that this is by design, not a bug. It’s always been that way, with every spreadsheet since Excel, maybe before. Memory fails me whether Lotus 123 did it or not, but I think it did.
Every iteration has just done it the way it was done before. Perhaps if we had you back then to set the original designers straight we wouldn’t be in this mess.
(Oh, and it is possible to save in ways that preserve the leading zeros. You just have to know how and that it’s not by default.)
BTW, @SevenSystems, I don’t know if it’s been mentioned earlier, but the way I’ve always ensured numbers remain formatted is to convert all cells to text before exporting to CSV.
I also use “Tab” or something other than comma as the delimiter. With tab delimited files you don’t have as much chance of a wayward comma in a formatted number from throwing the import off. You can also then more safely go without quotation marks around strings.
Exports are also notorious for putting quotes around strings that have spaces in them, but not putting quotations around anything that looks like a number. You gotta watch all that and make sure to find export options that are consistent if you’re doing any kind of parsing script. Something as simple as one person having different Region/Language preferences than another can cause havoc.
If nerdy IT stories weren’t so lame I could reel off dozens of stories just about accidents caused by people not realizing Europe and the US use commas and periods in different ways in numbers. Some very, very expensive.
Did anyone try the csvt thing I posted earlier? I’d like to know if that ever works and under which circumstances
@wim the CSV file came from my own exporter which is written in PHP (yes, I know. It's a legacy system and I was young and stupid). I enclose every cell in quotes there, it didn't help...
But yeah, I wonder why there's no more generic agreed-upon standard for exchanging tabular data between programs.
Well, I myself love JSON and do pretty much everything with it (note how all of Xequence's file formats are JSON-based). But I don't think spreadsheet software has import functions for it? (any kind of table could for example just be represented as an array of arrays, and basic type information would be included for free.)