Posts by BrownDog

    If you don't mind my asking:


    Are you using the KPA_TAG_Editor developed by Laurent (GuyTarero), Waraba others to extract the data from the backup and later import it into to your "database"? Just wondering, because that is what I have been doing while trying to find a suitable database front end for the MAC.


    In that case you should be aware, that an essential part of your routine is non-commercial open source code granted to the free use of this boards members generously.
    If you "crack" the tags from the profiles yourself, then please forget, that I ever asked.

    Hendrik (and for everyone else) I would like to clarify this (sorry for the jargon):


    The application I am developing is a WPF application (.NET), developed in C#, with telerik user controls (I am a licensed developer) and using SQL Server Express as the backend.


    The tag editor applications that are elsewhere available in the forum, developed by Laurent and the others are python scripts, based on an open license generic midi (kipr files are just midi files) file reading/writing tool.


    I have looked at the scripts as a reference and as I have posted before I give credit where its due.


    Now even if I wanted to, there is no way of porting python scripts to c# code directly. I actually searched for a generic midi c# library that would give me a starting point and surprisingly couldn't find anything very useful. So I have actually written one from scratch.


    The only thing reused from the tag editor scripts were the labels for the rig tags, cause I was lazy to type them again :whistling: .


    I am glad you asked and hope that this post clarifies this subject.



    Now regarding the possibilities for a MAC version, I would like to thank you for your background info and suggestions. I do not have experience developing for the Apple OS platform and this is the main reason I am doing a windows version first, so I cannot provide much input on what would be the best option. If someone is willing to develop it I am more than willing to share my source code, notes and help out in any way I can, while let him/her take full credits for the app (and financial benefits).


    Another option might be to host the backend on a cloud service (my website is already hosted on the Azure platform) and have the Apple version be just a thin client. The obvious downside to this would be the need for an internet connection to access the database. Not the end of the world these days, but can be a pitfall. Again as I said my experience with developing for the Apple platform is very limited so I am not the best person to make this decision. If no one is willing to do it I will gladly look into it as soon as the Win version is rolling.



    My thoughts were to maybe make something similar to "Steam" (if you´re familiar with it) out of this. Basicly a Steam but instead of games with Rigs on it - maybe a direct link/connection with the rig exchange so people can download their rigs right with this manager. Maybe even some inter-conectivity between users of the application. I hope you know what I mean.


    This will be done with all rigs that are hosted in my website. I cannot host any rigs that I do not have express permission for from the creator.


    I would love to be able to tap into the official Kemper repository, but since they are developing their own application I have a feeling they will not be keen in allowing me to do so. Maybe if we all ask really nicely? Mods? Mr Kemper? Any chance of this happening? :)

    Do not forget the first free tag editor (PC and Mac) that was released Saturday, July 14th 2012 (search for "Profiler Rigs Tags Editor" thread , in Introduce Yourself section of the forum, currently on page 4)


    Totally right Laurent!. My apologies for the omission. At the time I joined the Kemper party the other version was already available, so my bad here for forgetting the roots. :)


    - Being able to attach a JPEG to each KIPR , that way we could put a photo of the amp, (that would envolve having a space on the view for it , wouldnt need to be a large area ).


    -Having a Text box for us writing our notes on the particular profile


    -Being able to attach a Wav , mp3 file and play it, for demo purpose .


    It will support custom tags (that will include a large text field for writing whatever notes you want against a profile).


    Attaching a sound file is on my todo list, just not sure if it will make it for release 1.


    Will add the amp image to the todo list (but what about effects, stomps... ?( )

    Thanks again guys for your encouraging support. :thumbup:


    Would like to make a note, that this would have been much harder without the inspiring work of the user trebie on the kipr tag editor. Whenever this goes live I fully intend to give him a percentage of sales. Let me know if you see this, otherwise I will send you a pm.


    For all you mac guys, I won't be able to port the application in time for the first release (if I want to release it before the end of the year... :pinch: ). I promise I will start working on it as soon as I have a stable beta version out, while it is being tested. Another option would be to find someone who has experience developing Mac (mono) applications and is willing to work with me on this one. Drop me a line if your interested.


    Cheers,

    Thank you for all the feedback. It is very encouraging. :D


    I am working as hard as I can (everyday after coming home from work) and I expect I can put a beta version out sometime in November.


    Yes, it will be paid software, but expect the cost to be in the ballpark of ~25$, so I think that will be a good deal. I haven't finalized the pricing structure so suggestions on this camp are welcome too (free is not a suggestion ;) , I do need to pay my bills...)


    I will support additional tags that are stored in the software database. I will try to incorporate a dynamic tag system that will allow users to define their own additional tags, but I will maybe limit the number to something like 5 or 10 (suggestions?). A fully dynamic system means a lot of additional development time that I am not sure is necessary.


    A rating system will be incorporated where not only you can rate and comment on the tags on your system but (SPOILER) your comments/ratings can be uploaded to our website, that will allow users to search shared kipr files by their ratings. More on this will be announced soon.


    Again, thank you for your feedback and keep your suggestions coming. :thumbup:

    A MIDI file is the one of the most appropriate structures to store MIDI data


    Totally agree with you there Timo. Just am not sure if a file that contains the metadata information that for instance a rig contains can be called the typical MIDI data.


    But this is a matter of discussing development architectures which is something I don't intend to do here.


    But if the explanation is as simple as it was to leverage the existing tools to manage/comunicate/debug midi files I can understand why it was done this way.

    I have been playing around with the kipr files (rigs...) and am trying to figure out what was the thought process to use the MIDI format for this files, that are used basically to store metadata (TAGS) and the data relative to the profile.


    Only things I can think of is if Kemper was/is thinking of using the sync mechanisms available to MIDI to sync this files with other kempers or other hardware that could use them in any way.


    Any thoughts?


    PS:


    For those of you who have no idea why the MIDI file structure is not the most appropriate to store info+data here is a very brief overview of its structure:


    Midi File Header
    Midi Track(s)
    Delta Time
    Midi Event(s) -> This is where the kemper is storing each of the tags and stuff like amplifier settings. One tag per event, so far and so forth.

    As promised here are a few more.


    I didn't have much time over the weekend so only 3:


    https://www.dropbox.com/s/cl8s…013-09-30%2021-55-58.kipr


    https://www.dropbox.com/s/ieqa…013-09-30%2021-49-42.kipr


    https://www.dropbox.com/s/uln2…013-09-30%2021-45-10.kipr


    I tried to get some decent ones from the "Discography" presets but couldn't do anything decent with the ones that included stomp boxes, so ended up taking them out and profiling the 3 different amp variations on the collection (JCM Slash, AFD100 and AFD100 in #34 mode).


    To be honest with you I haven't used Amplitube since I started using the Kemper and going back to it, the difference between the 2 is insane. A completely different league. And I used to love Amplitube... :wacko:

    if I got correctly.. you mean Kemper should/would be better to Add a series of DI tracks (recorded W/ different Guitar Types) As Optional Integrated part of the Refining process.


    Just one optimized DI would suffice it the differences we are experiencing between refining with a tele/strat/LP is ~1% (and that could be due to differences in playing while refining rather than the the guitar itself).


    It could Be the 1stWWar in terms of: What IS the Right Les Paul to refine With for a crunchy /smooth Creamy tone?? :D


    and What's the best telly..strato..semiacoustic?? :P

    Oh no, let's not start that discussion!!! ;)

    Used an epiphone les paul standard (2011) neck pickup if I am not mistaken since I did the profile at home (was done sometime in Aug).


    This profile is of the default preset. There are a bunch of them all the way from the AFD record to to Snakepit and the Solo album tracks. I will try to profile some from each era.


    IMHO though you will get much closer to the real sound with something like the TAF AFD100 profile than with the Amplitube ones, although they are pretty cool for what they are.


    First of all, nice test and thank you for your work.


    Was wondering if, as stated, the guitar used has no (or little) impact on the refining process, what stops kemper from including an optimized DI track at the end of the profiling process itself, without relying on the user to play whatever is their interpretation of playing loud chords for a while?


    Is it just to allow the user to play for different periods of times/ in different ways to keep refining the profile in certain areas? i.e. play PM chuga chuga to improve the bass response.


    If so the system could at least still do a standard refining with the optimized DI track and then let the user do whatever refinement he wants like it does now.


    This could even be an optional step for those who prefer the "purity" of the unrefined profile.


    Am I missing something here?

    No problem guys. Glad you find it helpful.


    I will try to keep it up to date monthly. I will also probably add the contents of the free packs that are available, we can have a zip with all the available free profiles on the kemper website.


    If you find this useful stop by the facebook page and like it if you have a chance. Website is up and running and the download page should be up next week with some other surprises coming.


    Time to do some more profiling. Cheers. :D